>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,
On another page the same command works fine. So, I now think, the reason in some other place. I'm investigating it now...
If it's not broken, fix it until it is.
My Blog