The general opinion on Mibuso is no, but this suggests yes:
http://support.microsoft.com/kb/874828/en-us
We are trying to host a Hungarian Navision database (classic) on the same server that already has a German database, has German locale. We have set everything, collation (not validated of course) , user language, everything except systems locale (language for non unicode applications), still the őőőő and űűűű stuff is wrong, and even more interesting is that it is differently wrong when entered manually than when restored from a backup. When entered manually the ű looks a bit off, when restored from FBK it is some 1/2 sign.
So currently it seems, not?
What are our other options without spending money? As virtualization is costly.
Comments
And now you are talking about the client machines, correct?
A NAV classic client accessing the german database needs to run on a windows machine which uses a german codepage. A NAV classic client accessing the hungarian database needs to run on a windows machine which uses a hungarian codepage.
If you are running the NAV clients on a terminal server you will need to setup 2 separate TS, one with german and one with hungarian codepage. There is NO way around this.
A few months ago I did an fbk backup and restore of a dutch and a chinese company both on a german system. So probably it does not matter what the codepage of the client is which runs backup and restore as long as both backup and restore are done on a machine with the identical codepage (but that is a guess).
FD Consulting
In my mind server and client is the same thing: I find supporting local client installations is annoying and kinda outdated: terminal server on the sql server, everybody using it directly there, and not having to worry about exactly what build which laptop has installed.
Thanks for the info. The documentation is really misleading here...
For me the machine hosting SQL has exactly one job to do and that is hosting a database. The NAV client could be installed on the local machine or on a TS but never on the SQL machine.
I can understand why you say MS docmentation is misleading - I would say MS documentation is absolutely correct.
FD Consulting