>Hi Fabio,
>
>>- use of the string variables into VFP command.
>>

? LEN(m.String)
>? LEN(@m.String)  && don't copy the string into the VM buffer

>I've wondered as well why such an approach seems to be missing. Only because of Len(StrTran(,,)) or Len(alltrim()) contructs ? Could the parser use MDotted variables to automatically use such an optimization across other vfp internal functions ? And this seems to have gotten worse in vfp9, probably some checks against buffer overruns.
>

Hi Thomas,

Not there is some technical reason in order not to make it.
However I always prefer that he comes given the control to me of the optimizations.

An VFP's optimization is:

 vString = vString + cExp

if VFP has space in the heap, then it do:

  vString = @vString + cExp

but with some expressions this generate bad results.

In the LEN() case the situation is the much simplest one,
why the lenght value is stored as an variable's attribute.

>>and many others are more useful.
>A few of my pet peeves: I'ld like to have an option to mark a function called as "inline".
>In the case of redundancy saving 1 - 3 liners without need of a local stack this can eliminate the call overhead of a function in often called loops. And NO redundancy in the code <g>!

Good.

>Or perhaps have a new keyword specifying [optimize..nooptimize] for each condition:
>sometimes for an application it makes sense to have multiple indices describing subset filtering, while at certain queries I'ld like to use only a specific index with high selectivity - relieving me from those ugly if seek() - scan while constructs. Probably the best way to speed up apps with large dbf's or LAN-bottlenecks.
>

Agree.
You can control this now ( partially );
put the index key to right

* this uses index1 and index2
... WHERE index1Exp=filterValue1 AND index2Exp=filterValue2
*  this uses index1 only
... WHERE index1Exp=filterValue1 AND filterValue2=index2Exp

regards

Fabio