Just one simple hint which should resolve everything: in dabatases and data management, and, more generally, almost anywhere except the UI, don't work with string representation of data, work with data itself. Use appropriate database data types, such as numeric. Not only you save on space and processing of data, you save yourself from trouble. Avoid parsing strings and invalid data; you parse or interpret data only when if comes from the user input, which is culture sensitive, error prone but human-readable,
Cultures is just one additional benefit of it. Data is culture-neutral, its string representation is not. Your 100.000,56 in binary form is the same in all cultures. If this is floating-point, it is governed by standard IEEE 754 (see), and so on.
In response to comments to this answer:
Please see my comment where I advice to rely on the culture specified as the culture of your thread; there are two separate properties:
You can assign the culture at any time during run-time. The satellite assemblies will be loaded according the fallback
mechanism I described in comments below. Of course, it won't change the look of the application immediately, as the data from resources will come up only when you use them, so you will need to invalidate anything which is involved and culture-dependent.
In your explicit calculations, the
of the thread affects the behavior of the methods which are not culture-neutral
. Besides, the API allows you to pass culture as a parameter. Let's consider, for example,
Try to use them passing the instance of the
where the parameter of the interface type
is expected. You can do it because this class implements this interface. If you do that, the string will be formatted as required by the specified culture. Please see: