How can it possibly currency setting affect database server operation. You should store numbers, not strings representing numbers, no matter is that currency of not. And numbers, by their nature, are culture-neutral. You need to take care of the presentation of the numbers in ASP.NET, and set the threads to required cultures.
Actually, MySQL does have culture-related settings, but it's mostly related to the calendar:
http://dev.mysql.com/doc/refman/5.0/en/locale-support.html[
^]
http://dev.mysql.com/doc/refman/5.0/en/locale-support.html[
^].
Also note that dollars remain dollars even if they are written in different culture. It all depends on what you calculate. If you only calculate the currency of only one kind, you don't even need to carry information on what the units are. And if you do operate with different currency units, the real issue is the (ever changing) rates.
It's not clear how "setting the culture to nl-BE in my website does not help". How come? Of course it does help, but the culture comes into play when you format number for showing them on screen. Please see:
http://msdn.microsoft.com/en-us/library/system.threading.thread.currentculture(v=vs.110).aspx[
^],
http://msdn.microsoft.com/en-us/library/system.threading.thread.currentuiculture(v=vs.110).aspx[
^].
If you do it, you will see that numeric data formatting is affected by the culture choice. Please see all the
ToString
methods of the numeric type(s) you use.
See also:
http://msdn.microsoft.com/en-us/library/system.globalization.numberformatinfo.positiveinfinitysymbol(v=vs.110).aspx[
^],
http://msdn.microsoft.com/en-us/library/system.globalization.numberformatinfo.negativeinfinitysymbol(v=vs.110).aspx[
^].
This is how you get your currency symbol:
http://msdn.microsoft.com/en-us/library/system.globalization.numberformatinfo.currencysymbol%28v=vs.110%29.aspx[
^].
This way, your application can be globalized. You don't have to hard-code dollar or euro characters, you can set current culture as required and get the default currency symbol.
—SA