on 8/30/01 8:58 AM, Francois Van Lerberghe at fvanlerberghe At freegates D.OT be
wrote:
>> Store the money values as a string with two-decimals. Define a virtual
>> method which converts that to a number; this can be used for sorting/find
>> operations if needed. The string field can be brought into RB very easily
>> and with no time penalty. Use the format function with a format
>> specification "#.00" or "#,00" as needed.
>
> Ok. But when you use the field to do calculation, you'll convert the
> string into double. So why don't use directly VDouble ?
Strictly to avoid the "representation" problem.
> I think converting the string into double lost the precision of the
> string representation.
Actually, it doesn't lose any precision however it does lose precision in
its appearance.
> So using directly VDouble avoid the need of
> conversion and, for large database, the time penalty. No ?
Several points here.
Using vDoubles will not avoid the representation problem. The only way to do
this is either string representation or integers. Both will require some
additional work.
I suggested the virtual field yielding the numeric value just because
numeric strings will sort differently if they are sorted numerically or
alphabetically. This gives you the best of both worlds since virtual fields
take up (almost) no space in the db.
In my work, I have found that bringing the data in as a string and then
using val or cdbl for conversion to numeric has negligible time impact and
gives me a consistent way of manipulating the numeric data.
Also, a minor point to be sure, the storing of the data as a string avoids a
number of conversions which are ordinarily necessary in sql statements.
Best regards,
John Roberts
mailto:jarobe01@athena.louisville.edu
©2001 john roberts |
