A bug, huh? It would seem so. You are good at finding them Fabio. I'm always amazed at how they continue to ignore bugs that have existed for so long. Some are hard to fix since you might actually break code, but I think there are many they just didn't want to fix. It still irks me that they would not fix a particular bug I reported (and you investigated further and reported about it here on the UT as a comment to my file in the downloads section that showed the bug). That bug could result in an unintended record pointer movement and therefore it compromised data integrity, but they just couldn't be bothered to fix it. I don't expect a fix for it in VFP 9 SP2 and so therefore it will never be fixed.

>Hi Russell,
>
>For this question the answer is simple:
> Because the designer, at design moment was stupid
>otherwise the design can't to be called stupid.
>
>But this is not the case.
>
>This is not a by design feature, it is an old bug:
>

>clear
>SET DECIMALS TO 1
>SET FIXED ON
>* VFP apply SET FIXED ON perform a ROUND(,1) and apply the TRANSFORM() behavior : Removes trailing zeros
>? TRANSFORM(1.289) && 1.3
>SET FIXED OFF
>* VFP apply SET FIXED OFF don't perform a ROUND(,1) and apply the TRANSFORM() behavior : Removes trailing zeros
>? TRANSFORM(1.289) && 1.289
>
>SET FIXED ON
>* VFP apply SET FIXED ON and perform a ROUND(,1)
>* after apply the TRANSFORM() mask
>SET FIXED OFF
>* BUG: the developer forgot to check SET(FIXED) and
>* VFP apply SET FIXED ON and perform a ROUND(,1)
>* after apply the TRANSFORM() mask
>? TRANSFORM(1.289,"@R 99.####") && 1.3000
>

>
>WORKAROUND ( but it open other issues ):
>

>SET DECIMALS TO 18
>

>
>Fabio
>
>>>Well, that's how it is. Re: TRANSFORM() question Thread #1126152 Message #1126159