>>I have a cursoradapter with .wheretype=3 and a case where sending updates fails because of a n(10,2) field. The field is numeric(8,2) on SQL side, and n(10,2) in .cursorSchema property. The update statement looks like this:
>>
>>update ... where ... and myNumField=0.57999999999999996 and ...
>>
>>The value in the table is, of course, 0.58 and I don't know why does the VFP's parser convert the value into this IEEE equivalent and whether there's a setting somewhere to set it right. If everything else fails, I can switch to .whereType=1, but I'd rather not do that if I don't have to (as it would require using a subclass of the CA that I use everywhere and then still wouldn't fix the problem if it reappears elsewhere, where I can't use wheretype 1).
>>
>>Anyone know a trick?
>
>You could clobber the SQL statement into something workable in a .Beforeupdate, but that would only be patching things up and still require subclassing.
>We usually use .wheretype=4 but with incrementing integers instead of timestamps

Found out that while the default for cursoradapter is wheretype 3 (key and updated fields), setting the 2nd parameter (forceupdate) to .t. in tableupdate() actually makes it use 1 (key only). And that I've hit a case where I didn't use that parameter and didn't use the custom adapter class (wheretype=1) that I already had. So this is an oddball case and it failed only in some rarer cases. Which only made it harder to find and still did some minor damage.

However, the main thing here is the parser itself - why does it pass 0.58 as 0.57999999999999996, and declares a n(10,2) number as float in the parameter list? Not only in a where clause, it's just about anywhere when I insert values using ?var notation in a SQL statement.

I could write a parser, but it would take me two weeks which I don't have.