>>>This is the same question as in the other thread (and it's solved there), but this time I only want to know this:
>>>
>>>When I send a SQL statement containing a field value, like ", ?alias.field, ...", and the field is numeric (i.e. not integer, not float, haven't checked for currency), VFP's parser sends it like this
>>>
>>>

exec sp_executesql '{sql statement here}', '...parameter list..., @p21 as float, ...', ...., {my field value as float}

>>>
>>>The case at hand is that the field with a value of 0.58 gets passed as 0.57999999999996 (didn't count the nines, but it's the usual 15.5 significant digits). Does anyone know how to tell fox to pass it as numeric, or generally how to avoid this kind of rounding error (and numeric types are supposed to be immune to this, when passed in text format)?
>>
>>the VPF ?cast(m.var AS I) work,
>>but CAST(m.var AS N(5,2)) not work.
>>This because N(5,2) is a formatting declaration over the float.
>>The issue is a design lack because when you read SQL decimal,
>>VFP map it to numeric field.
>>
>>Naomi says, only in the SQL Server world a value can exists as a decimal number.
>
>Yes, that's my conclusion too. The VFP parser gets the expression as either integer or general numeric (and perhaps currency), and sends in that format. Nadia's solution would work when passing parameters; for passing values from cursoradapter it's a bit irrelevant because the rounding which occurs SQL side gets the values stored correctly.
>
>Tried this yesterday
>

select case when 0.58=0.57999999999999996 then 'equal' else 'unequal' end
>select case when 0.58=CAST(0.57999999999999996 as float) then 'equal' else 'unequal' end

>and got that the first one returns unequal and the other equal on SQL 2008R2 and SQL2014, so even in a where clause, if it was passed as a ?var parameter, it would still work correctly because VFP parser does declare it as float - the 2nd case applies.


you are optimistic.
years ago, when I was discussing with the developers of Microsoft VFP on this website,
if I remember correctly I found cases where the conversion of SQL to decimal
returned values with the last decimal different from what it has in VFP.
I tried to make him understand that the float is not the appropriate numeric format for the additions,
but I did not succeed.
Then I got bored, they have closed cabin and puppets, and the story is over.
To have a reliable, I do all computations in SQL Server,
and VFP is just a graphical viewer.