The comma doesn’t replace the dot in non-US systems.
on french systems “5.2” is displayed as “5,2”
And on UK systems it is displayed as 5.2
I don’t see any difference between US and UK concerning the number displaying
except may be $ <-> £
?
so using .currencyvalue on a UK system may work correctly ?
The point I am making is that some of you should check that assertions you make are actually correct, before making them.
Yes, as you noticed later.
The same accounting app that works when someone is doing VERY BASIC tests in the USA, loses $ millions from the balance, or could potentially pay lots of wrong taxes when run in some other country or even in USA when the machine is configured with another locale.
We are not talking about a presentation level error like a garbage when printing some data, but a basic data loss, at the math level, ending with very bad calculations, causing a potential, very bad, money loss.
Everything can happen when 1234567.89 becomes -0.5808 for no reason.
The basic data and conversions, I/O, math, Database objects and functions needs a review and tests looking for more affected areas than what was found here in DatabaseRow when the locale is not the US one (in the tested case, one using comma as decimal separator).
1 Like
ALL of your opinion seams irrelevant and out of place. Did you read the thread?. The data is stored as a double and converted to a Currency. No money symbols, spaces or any other text is involved. And this is not some random user text, everything is done INTERNALLY, from the Double to the Currency, so yes, it is something to blame them.
1 Like
The data is stored correctly, the data retrieval function provided by the language, used correctly, but not well tested by the QA for most scenarios, corrupts the data… it’s simple as that.
What to do? A quick review looking for more points of fail, a quick fix, and fast Release of a 2021R3.2 ASAP! Before the 2022r1 cycle to start.
1 Like
67133 - Severe data corruption tied to values processing wrongly under some locales
1 Like
From what I understand this is a locale problem that affects regions that use comma instead of period for decimal separator.
Mexico is not affected because we use period (same as the USA). I think Brazil and Argentina use comma.
I thought that all of the of the Spanish past colonies used the Spanish system. Never thought that Mexico had lost its heritage due to proximity to the USA, but I just learned that Mexico and Guatemala do it. In South America just the Guyana uses a dot instead of comma as far as I know, due to its English heritage. Comma is the most used decimal separator per country, but not per capita, because China and India uses a dot too.
Never mind that a British Billion was
100,000,000 whilst the US has always been 1,000,000,000
A million million vs a million thousand 
And slowly England adopted the Imperial standardization, whilst keeping metric units 
The old UK meaning of a billion was a million million, or one followed by twelve noughts (1,000,000,000,000).
The USA meaning of a billion is a thousand million, or one followed by nine noughts (1,000,000,000).
Increasingly in this country we are using the USA meaning of a billion for these big numbers, and a trillion for the old UK meaning of one followed by twelve noughts. The UK government has been using the American meaning of billion since 1974 for the numbers it gives out.
This appears to have been a bug in the database interface layer and thus not specific to SQLite. William checked in a fix this morning. Once we have a 2022r1 test build, you can confirm that it’s fixed with your own code.
6 Likes
nice to see an answer to this old problem.
also “happy” to see that in my previous posts I spotted a global database problem
with currency not only for sqlite . and I was right.
have a nice day.
1 Like
You where posting about being the CurrencySymbol and DecimalSeparator when saving the data. that has nothing to do with the bug 