Walter, thanks a lot for this information.

>Hi hilmar,
>Incrementing keys are ofter the cause of unbalanced indexes, Since most indextypes are based on the B-tree mechanism, all new values are added on the outhermost right side of the three. When a node is full, a new child is added on the rightside again (and so on).

Yes, that's exactly what I was afraid might happen. So, neither the SEEK() command, nor a query or view are "safe" (since they all rely on the index).

I guess I'll have to reindex more frequently.

>In the worst case the B-Tree isn't a B-tree but a sequential file of indexvalues. ...

That must be what happened to Nadya.

>When having lot's of keys (records) in the index seeking an indexvalue can get slow. Reindexing the file should get a new balance where all values are equally spread in the B-Tree. Theorecticly SEEKing a value in a table of N records would require at most 1+ INT(LOG(N)/LOG(2)) steps.

Theoretically, that is, if the index is completely balanced.

I guess you could simplify the expression above (in VFP) to ceiling(log(N) / log(2)).

Hilmar.