Hi Aleksey,

two other things only related generally to SQL and the practices where the bug was found, not the bug itself, but which nag me sometimes:

YAG mentioned at the german vfp conference 2 or 3 years ago, that Celko's books were considered yardsticks for the vfp SQL implementation. Now Celko describes the SQL-update process as working from a copy of the original values, so that the order of the elements in a multi field update is irrelevant.

The vfp implementation of update SQL works like the replace: if a field is updated and later in the same statement used as the source of the next assignment, the UPDATED value and not the OLDVALUE is used - which contradicts Celko in that matter, but is familiar to everyday vfp/xBase use.

Main Question: Is this an "implementation detail" which will remain or is there a possibility of a change to the behaviour Celko describes ?

When coding "for myself" I implement any field chenges dependant on updates in the same statement (which sometimes really is a work-saver<g>) as "replace", but at the place where I found the udf-bug there is a strong tendency to ALWAYS use SQL instead of xBase whenever possible. So there are sources of mine which would definitely break if vfp-SQL would follow the behaviour Celko describes as standard. If there are plans for a change in vfp, I'ld ask for a specific set/sys()-call just for "update from current/latest updated field values" vs. "update from copied values" and not some global switch like "Set enginebehaviour".

The second is even less related to SQL but more to my personal style of coding and xBase/vfp behaviour: in xBase the table field to be changed can be coded as a name expression

replace all ;
     (loFldVar.Plz) with "60435";
   , (loFldvar.Street) with "Koselstrasse 18A";
   in (lcmyTable)

as well as Macroexpansion

replace all &lcPlz with "60435", &lcStreet with "Koselstrasse 18A"

whereas the update - SQL works only as Macroexpansion:

Update (lcmyTable) ;
   Set &lcPlz    = "60435";
     , &lcStreet = "Koselstrasse 18A"

Probably I should switch over to building the whole SQL command either in code or via Textmerge, but some habits are "just there". This often comes up when reformulating some fieldmapping code from xBase-code to SQL: espeially when the xBase already uses objects via for code clarity it nags me hard enough to test again<g>. But OTOH name expression works with "store" only and not the typical "myTarget = mySource"...

regards

thomas