View Single Post
  #8  
Old May 12th, 2009, 12:02 AM posted to microsoft.public.access.tablesdbdesign
David W. Fenton
external usenet poster
 
Posts: 3,373
Default Backend Database

"Douglas J. Steele" wrote in
:

In addition to the advice you've already gotten, take a look at
http://www.mvps.org/access/tables/tbl0006.htm at "The Access Web"
for how you can continue to use Seek (although there's really no
reason to)


That latter is the real point. There are only a handful of scenarios
where .Seek is useful, and that involves a circumstance where for
some reason you need to jump around a rather large recordset a large
number of times (10s of thousands of records or more, 1000s of jumps
or more). This was discussed at length with some (questionable)
benchmarking results in the thread where I made this post:

http://groups.google.com/group/comp..../msg/585927e7e
a5ed7dc?dmode=source

That post shows how I tested optimizing .FindFirst. The reason
..FindFirst is slower is because each time you call it, it starts
from the top of the index. Thus, the time a .FindFirst takes is
roughtly proportional to how far down the index the value you're
looking for is.

Thus, in my test, I optimized the Find operations to check the value
of the current position versus the requested new position and chose
FindNext or FindPrevious appropriately. This cut the time needed by
half (which is statistically exactly what you've expected). And that
testing convinced me to do this in all large recordsets where I'm
jumping from record to record with the Find functions.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/