>>>Did you try with old plain STR()? :) Also, could it be the problem in SET DIGITS, SET DECIMALS, etc. They could be different in your DLL and your test form - just guessing...
>>
>>SET DIGITS?? There is no command like this in VFP. I've used STR() to display as much of the result as is possible and both values are identical. SET DECIMALS is the same. I've even tried it with SET COMPATIBLE ON and OFF (as mentioned in KB article Q247494. I've this tried on VFP 6.0 SP3 and SP4. I've tried it in the run environment and in the design enironment.
>
>I probably meant set fixed. Well, do you have enough precision in your table? How does VFP store numbers? Have you tried to store numbers as char strings and convert them to numbers in your calculations?

I think you meant decimals.

First, I have no control in the production environment over the data source. It's SQL Server. Information regarding one part of the calculation is coming in as tiny ints. The other is a string resentation of a fraction (which is evaluated to return the decimal (in this case 1/10 or 0.1000) and a decimal with 4 decimal places. In the VFP views the tiny ints are integers and the decimal is a 9, 4 numeric. I've modified the integers to numeric with no change and the numerics to a double precision with 4 decimal places, without a change.

It should be noted that in production these are properties being set from another product. However, I get the same results from with VFP.

>>As near as I can figure out it: A. Only applies in a DLL and only with certain values; and B. Those values must come directly from a table. When assigning the exact same values by using literals (haven't tried memvars from a table) the DLL works as expected.
>
>Weird. Perhaps this could be addressed as a bug.

I've already contacted MS.