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)).
>>
>>Hmmm, are we running some sort of contest of getting the shortest code again :) ?
>>
>>Walter,
>
>It could be a thoeretical puzzle for you, but it's not that easy for me :(( I have a site, which is not working. More precisely, it works for ID<1000, but when I increase ID, the time spent gets bigger and bigger and finally it gives timeout.
>
>Yesterday I tried all combinations and was unable to make it work with big numbers. I don't have control over the server, I can only download and upload files from one directory (not from Data directory). I don't have database to test locally. I don't have a tool to test my changes locally... The only way for me to test is change page locally, upload and try, then again and again...
>
>If you're curious, drop me an e-mail at nosonov@msn.com (I'm at home today), I'll give you some instructions.

Well, a ill balanced index would show exactly the problem you're experiencing, however there could be other restrictions also. So my first try would to simply REINDEX the table.

You can also write a program that:
1. opens the file
2. make a non structural index with INDEX ON MyIndexedField TO test.idx (you don't need to have exclusive access for that)
3. Test if this gives the same performance problems as with the structural index by seeking the large numbers.

4. If it doesn't, the problem most certainly is in the original index. A reindex might help. Maybe its even better to do a DELETE TAG ... and INDEX ON.

Feel free to E-mail me on Tax@Tref.nl, but I won't be online until tomorrow morning (your time).

Walter,