Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 15 of 15 total |
Anybody using TIntegerField to store currency values? |
Thu, Jan 25 2007 12:30 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Sean,
<< Use a TCurrencyField - you won't regret it. >> TCurrencyField is the same thing as a TFloatField. Only the TBCDField will use the Delphi Currency type and not encounter rounding errors. Usually the maximum scale of 4 decimal places for the Currency type is plenty to handle any Currency calculations. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jan 25 2007 3:08 PM | Permanent Link |
Sean McCall | Tim Young [Elevate Software] wrote:
> Sean, > > << Use a TCurrencyField - you won't regret it. >> > > TCurrencyField is the same thing as a TFloatField. Only the TBCDField will > use the Delphi Currency type and not encounter rounding errors. Usually the > maximum scale of 4 decimal places for the Currency type is plenty to handle > any Currency calculations. > Tim, You are almost correct and I was obviuosly wrong in my assumption that TCurrencyField buffers or stores its data as a Currency value. If you look in DB.PAS, TCurrencyField descends from TFloatField and differs in the constructor. A TCurrencyField has a field type of ftCurrency which controls how the data is formatted for display in a grid or edit control (see TFloatField.GetText). I am surprised that borland did not change the .Value and .AsVariant properties to return a currency type, but perhaps they wanted to maintain backwards compatibility since D1 had no currency type (don't know when it was introduced). Also may be that most databases store currency / money as a formatted floating point. When I read currency field values I tend to avoid using .Value and ..AsVariant. I use .AsCurrency out of habit so I haven't had problems. For me the key is to always read or write into a Currency type variable to get a value with no "approximation error". I think "approximation error" is probably better term than rounding error for this discussion since I'll use it to refer only to the fact that the binary fraction in a floating point value is sometimes only an approximation of a decimal value. Approximation error comes into play when formatting a result for display and should rarely if ever concern computational accuracy for currency values. A currency type has 19-20 significant digits, double precision has 15-16. Both should be plenty for storing real life money values. Rounding error is actually *more* likely to happen when performing cumulative calculations on a currency type than a double precision floating point type because the result will be rounded to the precision of the variable type each step of the calculation. It really depends on what kind of values you are using in your calculations. If you routinely divide by any number or multiply by fractions that have lots of precision past a decimal point and do this in multiple steps you need to make sure you are not losing accuracy because of cumulative rounding errors. What it boils down to is that there is no right or wrong ways to store currency values. No matter what field type one uses it is critical for the programmer to be mindful of all the issues when dealing with currency (and actually any numeric types). Namely computational accuracy including rounding errors, validation before storage, and binary fraction approximation which relates to display formatting issues. For money, my preference remains ftCurrency / TCurrencyField since grids, data aware controls, and third party tools like report engines can recognize that the value represents a currency value and can therefore properly format the value for display without my intervention. Sean |
Fri, Jan 26 2007 10:17 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
I can't seem to find a currency type in EDB Roy Lambert |
Fri, Jan 26 2007 3:26 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< I can't seem to find a currency type in EDB >> DECIMAL is the type that you want. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Jan 26 2007 3:27 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Sean,
<< When I read currency field values I tend to avoid using .Value and ..AsVariant. I use .AsCurrency out of habit so I haven't had problems. >> True, that may remove any issues by always dealing with the values as the Currency type. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |