>
Why does this only partially optimize:
>
>select * ;
> from history ;
> into cursor xtemp ;
> where ( ( ltStart <= tCreated ) and ( tCreated < ltStop ) ) ;
> order by iMachineID, tCreated
>
>to get it to fully optimize it has to be written:
>
>select * ;
> from history ;
> into cursor xtemp ;
> where ( ( tCreated >= ltStart ) and ( tCreated < ltStop ) ) ;
> order by iMachineID, tCreated
>
>
>Why does the field have to appear on the left side or the operator??? Is this documented somewhere?
>
>I'd prefer to to write things more like the algebraic ltStart <= X < ltStop. But evidently rushmore is persnickety about coding that way. There is are indexes on tCreated and iMachineID.
I can't answer you directly, but can relay a recent learning experience I had with Rushmore.
I had a view that that was doing something similar to yours (simpler, actually),
it was something like:
SELE * FROM BondCard;
WHERE TimeStamp > WebSent
Where timestamp and websent are datetime fields.
There were indexes on both fields, but SYS(3054) revealed that it was only partially optimized (index on DELETED() too).
I even then created an index on timestamp > websent, and still no optimization.
To get it to optimize, I had to retain the index on timestamp > websent and restructure the view to read:
SELE * FROM BondCard;
WHERE (TimeStamp > WebSent) = .T.
Talk about persnickety. BTW, thanks to Barbara P. for the point in the right direction with that one.
Erik Moore
Clientelligence