something very strange here
I have on the Db a field have value of 17.55 when i read and show the Data show 17.50 i lost 0.05 way
i read the data like
TxtLoomisPos.Text=Rs.Field(“posloomis”).StringValue
or
TxtLoomisPos.Text=Format(Rs.Field(“posloomis”).CurrencyValue,"###,##0.00")
Same problem lost 0.05 in 1000 record i lost of .5 * 1000 =50.00 my accounting is crazy
[quote=60105:@Alexis Colon Lugo]something very strange here
I have on the Db a field have value of 17.55 when i read and show the Data show 17.50 i lost 0.05 way
i read the data like
TxtLoomisPos.Text=Rs.Field(“posloomis”).StringValue
or
TxtLoomisPos.Text=Format(Rs.Field(“posloomis”).CurrencyValue,"###,##0.00")
Same problem lost 0.05 in 1000 record i lost of .5 * 1000 =50.00 my accounting is crazy[/quote]
When dealing with money do not use doubles, the currency type is there for a reason - accuracy!
From text convert variant and then to currency via the CurrencyValue method. Having said that most accounting systems use integers internally for dealing with currency, with an offset for the decimal place.
IMHO currency values should always be stored in the smallest monetary unit of a specific currency as Int64. And then use multiplicators to format your data for the screen and the print-outs. Remember that:
some currencies have more than 2 decimal places, and
there are currencies which are non-decimal (the larger monetary unit is not 10, 100, 1000 times the smallest monetary unit).
MONEY datatype is sensitive to locale. It’s good and bad. Some people just prefer ignore the locale and use NUMERIC instead, like:
NUMERIC(*,4) //four decimals
That way, the database carries it’s precision with the data. Storing decimal values as integers, this info is lost, only an external program knows where is the decimal part, if there is one. Not a good practice.