>>>>Did you change the field type to Currency (Y)? If so, the data is stored as a BCD quantity with 4 decimal places; you need to alter the mask on the report form's field references, or convert the field to a Numeric for output using MTON(); Numerics respect the SET DECIMAL settings.
>>>>
>>>>Currency fields and variables have a nasty habit; if there is even a single Currency datatype in an expression, the type of the result of the expression becomes a Currency type. This can result in subtle rounding problems on multiplication, division and transcendental operations, different from those experienced by type N expressions. there are distinctive advantages to currency datatypes in addition and subtraction operations involving very large or very small quantities because of the BCD representation - the same advantages accrue to other math operations
AS LONG AS NO INTERMEDIATE OR FINAL RESULT HAS > 4 DECIMAL PLACES OF PRECISION.>>>
>>>I don't think it's BCD. It's an 8-byte integer internally, where the value is divided by 10000 when getting converted into other number formats.
>>
>>You may well be right; I assumed from the definition that it would be BCD, and I have not needed to work with the Y datatype internally using the VFP API - I should probably read the docs at least, and try passing it as a recast 8 byte string into ClsHeap to look at it.
>
>I also had the impression that it should be BCD when I first read the docs, and I was surprised, when I had to write a string-to-number conversion for it, that it's just an integer. I suppose it works faster this way.
That's an interesting thought - pass an 8 byte buffer to be filled by a signed LARGE or ULARGE value, and then use RTLMoveMemory() to pass the address back as a pointer to a Y; receive back the Y and multiply by 10^4 and you have the integer value of the ULARGE stored within the Y and then alterable and passable by reversing the process. I like this! You can do ULARGE integer math using NTOM() on integers * 10^-4; which is something useful to play with. A new GetDiskSpaceEx() implementation may have just hit the ground running.
