One of those days...
-
So, I shifted our web sites onto a 2008R2 box on Tuesday night, tested the sites all pick up, got sharepoint moved and upgraded, configured app pools etc ( some are 32bit because of a ghostscript dll ). All in all a smooth crossover and feeling quite good and ease of heart to go and vote in the next mornings elections. Then I come back in today. It started as a small suspicion with a poor user getting a basic error but only on a old website. Simple validation check that tested whether two figures matched or not. Then I spot that the currency format was showing all wrong. Our folks like to use R #,###.00 ( thats just for illustrative purposes ) and all my currency fields were displaying R # ###,00. Simple enough I thought, just pop on to the server and ensure it's region settings are correct. Ok, lets get on, check the region.....? It seems correct, location is SA but wait the currency tab is a bit messed, so lets just put correct decimal deliminator in as well as the thousand separator. So, all done, refresh the site. Um.... nope, still the ugly format. Ok, lets restart the website....nope. Recycle the apppool....nope, restart iis...nope, restart the damn server...nope. SO by now it dawned that it wasn't a persistence issue. So let's try changing it to something stupid like US.... nope. Now I was seriously confused, so I spent some time digging into all the possible methods of how a site can ignore a servers regional settings: ASP Globalization on a server and site level, globalization tags in the configs etc. All checked. I did find a en-za tag in the config so that explained the whole override why US wasn't working so that got removed and I got the website to work of the global settings. BUT, that damn little comma decimal separator still insisted on staying there. So I dug deeper: possible registry settings for users localization, edited the keys to the same standard, came across articles mentioning how asp processes may take on incorrect localization settings if changed post site creation. Then I found a gem. It appears that some standards body somewhere deemed that when South Africa started using the metric system (we always have for many years as far as I know) we decided to drop a period for decimal separation and replace it with comma. This was now updated into the regional settings of OS's post 2008. Apparently, it even only happens if you switch a site from ASP 3.5 to ASP 4.0 Thoughts of homicidal rage against the person who decided to change the cultural standard from pretty much what every So
-
So, I shifted our web sites onto a 2008R2 box on Tuesday night, tested the sites all pick up, got sharepoint moved and upgraded, configured app pools etc ( some are 32bit because of a ghostscript dll ). All in all a smooth crossover and feeling quite good and ease of heart to go and vote in the next mornings elections. Then I come back in today. It started as a small suspicion with a poor user getting a basic error but only on a old website. Simple validation check that tested whether two figures matched or not. Then I spot that the currency format was showing all wrong. Our folks like to use R #,###.00 ( thats just for illustrative purposes ) and all my currency fields were displaying R # ###,00. Simple enough I thought, just pop on to the server and ensure it's region settings are correct. Ok, lets get on, check the region.....? It seems correct, location is SA but wait the currency tab is a bit messed, so lets just put correct decimal deliminator in as well as the thousand separator. So, all done, refresh the site. Um.... nope, still the ugly format. Ok, lets restart the website....nope. Recycle the apppool....nope, restart iis...nope, restart the damn server...nope. SO by now it dawned that it wasn't a persistence issue. So let's try changing it to something stupid like US.... nope. Now I was seriously confused, so I spent some time digging into all the possible methods of how a site can ignore a servers regional settings: ASP Globalization on a server and site level, globalization tags in the configs etc. All checked. I did find a en-za tag in the config so that explained the whole override why US wasn't working so that got removed and I got the website to work of the global settings. BUT, that damn little comma decimal separator still insisted on staying there. So I dug deeper: possible registry settings for users localization, edited the keys to the same standard, came across articles mentioning how asp processes may take on incorrect localization settings if changed post site creation. Then I found a gem. It appears that some standards body somewhere deemed that when South Africa started using the metric system (we always have for many years as far as I know) we decided to drop a period for decimal separation and replace it with comma. This was now updated into the regional settings of OS's post 2008. Apparently, it even only happens if you switch a site from ASP 3.5 to ASP 4.0 Thoughts of homicidal rage against the person who decided to change the cultural standard from pretty much what every So
I think I know the period-and-comma pain you have had. I recommend you apply regional settings when interacting with users, and not when storing/retrieving data to/from files and databases; you then should use an InvariantCulture, which is constant and does not depend on regional settings. I also recommend avoiding strings for values that have their own type, such as numbers and DateTimes. :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
So, I shifted our web sites onto a 2008R2 box on Tuesday night, tested the sites all pick up, got sharepoint moved and upgraded, configured app pools etc ( some are 32bit because of a ghostscript dll ). All in all a smooth crossover and feeling quite good and ease of heart to go and vote in the next mornings elections. Then I come back in today. It started as a small suspicion with a poor user getting a basic error but only on a old website. Simple validation check that tested whether two figures matched or not. Then I spot that the currency format was showing all wrong. Our folks like to use R #,###.00 ( thats just for illustrative purposes ) and all my currency fields were displaying R # ###,00. Simple enough I thought, just pop on to the server and ensure it's region settings are correct. Ok, lets get on, check the region.....? It seems correct, location is SA but wait the currency tab is a bit messed, so lets just put correct decimal deliminator in as well as the thousand separator. So, all done, refresh the site. Um.... nope, still the ugly format. Ok, lets restart the website....nope. Recycle the apppool....nope, restart iis...nope, restart the damn server...nope. SO by now it dawned that it wasn't a persistence issue. So let's try changing it to something stupid like US.... nope. Now I was seriously confused, so I spent some time digging into all the possible methods of how a site can ignore a servers regional settings: ASP Globalization on a server and site level, globalization tags in the configs etc. All checked. I did find a en-za tag in the config so that explained the whole override why US wasn't working so that got removed and I got the website to work of the global settings. BUT, that damn little comma decimal separator still insisted on staying there. So I dug deeper: possible registry settings for users localization, edited the keys to the same standard, came across articles mentioning how asp processes may take on incorrect localization settings if changed post site creation. Then I found a gem. It appears that some standards body somewhere deemed that when South Africa started using the metric system (we always have for many years as far as I know) we decided to drop a period for decimal separation and replace it with comma. This was now updated into the regional settings of OS's post 2008. Apparently, it even only happens if you switch a site from ASP 3.5 to ASP 4.0 Thoughts of homicidal rage against the person who decided to change the cultural standard from pretty much what every So
I spent months fighting against problems caused by dot comma shenanigans at a previous company. We were UK based, for many, many years, then we opened a franchise in Italy and gave them a version of our software. This was a main Hub server and 20ish depot servers around the country sending information between each other, as well as various other imports and exports. Turned out the front end and the back end had been setup using different formats. So we kept ending up with values a hundred times greater than they should have been depending on how they had been imported and where they had come from. That messed with the invoicing a bit.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
I think I know the period-and-comma pain you have had. I recommend you apply regional settings when interacting with users, and not when storing/retrieving data to/from files and databases; you then should use an InvariantCulture, which is constant and does not depend on regional settings. I also recommend avoiding strings for values that have their own type, such as numbers and DateTimes. :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
Data persistence wasn't so much of an issue as the display. The system was actually set to an InvariantCulture but I understood that to mean that it uses the culture that is set on the server or am I mistaken? My main issue wasn't the culture, it was more that some standards body had sneakily enforced a culture that we don't use in this country.
-
Data persistence wasn't so much of an issue as the display. The system was actually set to an InvariantCulture but I understood that to mean that it uses the culture that is set on the server or am I mistaken? My main issue wasn't the culture, it was more that some standards body had sneakily enforced a culture that we don't use in this country.
Mario Luis wrote:
I understood that to mean that it uses the culture that is set on the server
No, it makes it independent of any regional settings. MSDN[^] could have said it better, it gives: The CultureInfo that is culture-independent (invariant)... The invariant culture is culture-insensitive. Your application specifies the invariant culture by name using an empty string ("") or by its language identifier. InvariantCulture retrieves an instance of the invariant culture. It is associated with the English language but not with any country/region. It is used in almost any method in the Globalization namespace that requires a culture. :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.