George,
This could be a problem with rounding and how many decimal places are displayed. I think outputting the values to text respects SET DECIMAL so the values may look exact. However, internal processing may have the values off by .000001 (not equal). My suggestion would be to use ROUND() where you need to to make the number of places decimal explcit to what you want.

HTH.

>I've experienced a rather strange situation with a COM object I've developed. As far as I've been able to determine, the results I've been getting are being affected by something external to VFP. First, the two environments.
>
>My development environment is VFP 6.0 SP4 running on a PII 350 with 128Mb running Win98SE. The test environment is a PowerBuilder application running on a PIII 733 with 128Mb running under Win2KPro. In both cases the underlying data is being retrieved from the same SQL Server 7.0 (SP1 I think) tables.
>
>During the course of process, my object attempts to validate the data it's received through various property settings from the table. Two functions are involved. One function sums a value whose source contained in an array like this.

FUNCTION NumberOfEnds
>  LOCAL lni, lnlast, lnresult
>  lnlast = ALEN(This.a_beams, 1)
>  lnresult = 0
>  FOR lni = 1 TO lnlast
>    * Both the values in a_beams[lni, 1] and a_beams[lni, 2] are integers
>    lnresult = lnresult + (This.a_beams[lni, 1] * This.a_beams[lni, 2])
>  NEXT
>  RETURN lnresult
>ENDFUNC

The amount returned is then compared with the amount returned from a function with this format.

FUNCTION NumberOfNeedles
>  LOCAL lnresult, lngauge
>  * cGauge is a string in the format 1/10
>  lngauge = EVALUATE(This.cGauge)
>  * nTuftedWidth is a numeric with up to 4 decimal places (ie. 146.4)
>  lnresult = This.nTuftedWidth / lngauge
>  RETURN lnresult
>ENDFUNC

Both of these functions are called from another method and the results returned are compared, something like this

lnends = This.NumberOfEnds()
>lnneedles = This.NumberOfNeedles()
><b>llresult = (lnends = lnneedles)</b>
>IF NOT llresult
>  * Set the error property appropriately
>  This.nError = INVALID_BEAMSET
>ENDIF

We ran across a situation where the comparison in bold was not being evaluated correctly. Further, we confirmed this by inserting a call to STRTOFILE() which output the values (using TRANSFORM() to change the numerics to strings) to a text file. Call was only issued if it appeared that the comparison resulted in .F.. However, the data in the text file matched exactly.
>
>I did come up with a workaround, as follows

lnends = VAL(TRANSFORM(lnends))
>lnneedles = VAL(TRANSFORM(lnneedles))

By inserting this code, the comparison is correctly yielding true, where before (with exactly the same data) it was yielding false. Note, nothing else in the code was modified. Again, this problem did not manifest itself when run on my machine using either the class directly or the COM object.
>
>Has anyone heard of anything like this?