Hi fabio,

I'm not sure what you're trying to show here. You're making an index on a function that returns a value that is not depended on any parameters and produces unpredictable outcomes. I don't see any application on that in rushmore optimizable expressions (while it can be of any value in xBase commands that directly access the index).

Index expressions are evaluated on INDEX ON, INSERT, DELETE and REPLACE actions (and all simular commands). However, an indexexpression is also evaluted for the first record when opening a table (which might explain the weird 1 record), normally this is not a problem as the most functions return the same result from the same parameters. Of course the DATETIME() function does not, and therefore producing confusing results.

Indeed if you turn off rushmore in DATETIME() = DATEITME() it would not look into the index but directly evaluates the expression that would return .T. in about all cases.

when rushmore is turned on, it seems that only one of the expressions is identified as index or both are and one is reevaluated (Vfps' rushmore is known not to do full index coverage and seems to evaluate the contents of the index anyways), resulting in a .F. because it the value in the index does not match the current value of DATETIME().


I'm not sure what you're trying to explain here.

Walter,