>>>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.

We did think a bit on what to base our CA logic on. DB_KEYANDUPDATABLE was ruled out from start, as Updateable list is often dependant on user (group) permission level and thinking through all possble issues in dependant biz logic for verification when a field might have been changed which is not in the updateble field list field for that user. Similar reasons for DB_KEYANDMODIFIED, too many possibilities validation might be led astray. When deciding to implement a basic record change counter we also had different TS representations in mind - Int was considered safe. So yes, we had issues like that on our map ;-)

Disallowing saving changes to buffered client data proven to have been changed serverside in the meantime cleans out many validation issues and is an easy concept to sell to the customer: if user gets work done quickly, chances of his buffered data being changed on the server is lower. Acceptance is high as we provide 2 different, but generic strategies besides abort for this type of situation: a generic mover type comparing his stale, but but in some fields user changed data with the current DB data. Second method gathers all changed data, gets fresh data from server and tries to automatically reapply those changes via biz level interface: this makes certain all client validation and user help is triggered. Only in rare cases 2. approach fails because a specific order of changes is not followed - usually order of screen entry works, but there are special cases. We don't try to permutate entry order to find a working entry path ;-)))

Selling mantra is: data safety is prominent. If data entry process is halted/slowed at user level, we try to help minimize double entry effort, but the responsibility for making entry process easier for the user by swift saving is left there ;-))

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

If you "enhance" to where between +/-err it should take less time, but even before estimating time needed I would argue very hard as it does not follow the KISS principle we try to have in our concept and needed implementations. Wheretype=3 is a flawed concept for me.

We do sometimes wonder if providing an option to refresh loaded data and reapply user changes not linked to .SaveAll, but under user control, would benefit or detriment user work flow - it could easily lead to unnecessary user actions, but Wheretype=4 with a counter is a nice clear concept (even if that sounds very german...)