This blog post is a Follow-up of what I have written
here:
The point I made was that SwissSalary depends on the (Swiss) regional settings. As of today, nothing has changed.
To avoid confusion: No. SwissSalary is NOT an international product. It's still a Swiss product for Swiss companies.
However there are some customers out there who have companies in several countries. Let's say one company is in Poland and one company is in Switzerland. What does that mean? What should the regional settings be like? Polish? Swiss? English? Should we actually care what the regional settings are? To answer this question: YES! You should care.
First let me tell you what Microsoft suggests for such a scenario:
You should have a database per country and the regional settings should be based on where they are. Full Stop.
But I can see that some partners and customers want to work on *one* database because of simplicity reasons and low-maintenance. However this scenario is error prone if you don't know how to setup the environment.
Ok, so here's what you need to know :
The first mistake happens when you import the FOBs.
The Dev.-Client (for importing FOBs) is NOT unicode. That means that the FOBs which we created with Swiss regional settings will be mangled when they get imported with different regional settings. That is when you have special characters in text constants or hardcoded strings. So the currently used code page matters! In our example: The code page used in Poland is different from the Swiss (852 vs 850).
Next, the C/AL code is executed on a service tier machine primarly and whatever settings you have there influences how the data is processed. For instance when you generate reports on the service tier the formatting of decimals, datetime etc. is based on the culture informations from the regional settings.
Next, Microsoft introduced the ENCODING-Property with NAV2013 R2 so that you can actually specify what encoding should be used when working with the FILE - variable for writing or reading files. This is a nice property but it came late to the party. With NAV2013 you still write OEM-Encoded files based on the code page used that on that machine.
Ok then... what's the solution for the *one*-database scenario?
Well, there is not a single solution for every possible scenario out there but here's what we consider as best practice:
Create different environments for each country (region):
RTC / Webclients should work with local regional settings according to their location but they should also be connected to a service tier which has the correct regional settings according to the user location. When dealing with the NAV objects, the Dev.-Client should also be used in the correct environment... depending on which objects need to be imported or compiled. That is cumbersome but that's the only way if you deal with NAV objects from different countries in one database.