|
|
Posted by Marshall Barton on 12/05/01 11:29
Neil wrote:
>I have a very puzzling situation with a database. It's an Access 2000 mdb
>with a SQL 7 back end, with forms bound using ODBC linked tables. At our
>remote location (accessed via a T1 line) the time it took to go to a record
>was very slow. The go to mechanism was a box that the user typed the index
>value into a combo box, with very simple code attached:
>
>with me.RecordsetClone
> .FindFirst "[Index] = " & me.cboGoTo
> If Not .NoMatch Then
> Me.Bookmark = .Bookmark
> End If
>end with
>
>Now, one would say that going to a record is slow because I'm using
>.FindFirst over a T1 line. And that's what I thought. However, as I was
>working with the form, commenting out various sections not related to the Go
>To, I found that the Go To functionality changed, though I didn't modify the
>code.
>
>Previously, going to a record near the end of the 50,000 record recordset
>took about 1-2 seconds, but going to a record near the beginning, took about
>20 seconds. After the form changed, going to any record in the recordset
>took about 1-2 seconds.
>
>So the question remains: why did it take so long to go to a record near the
>beginning of the recordset, but not near the end (and the ones in the middle
>took an amount of time about halfway between the two), and what changed so
>that now the form is working fine for all records?
>
>I've compared the changed form with the previous copy, and I don't see any
>differences. I've compared all code in the form module, and I've compared
>all form properties. The forms are identical as far as I could tell. But
>something happened as I was commenting/uncommenting code in the form that
>got rid of the problem with it taking a long time to go to some of the
>records.
>
>My first thought was that something got recompiled, and now the form is
>fast. So I went back to the original version and changed some code and
>recompiled, also did a compact and repair. But it was still slow. I also
>tried doing an explicit decompile and then recompiled it. But it was still
>slow.
>
>So this is very frustrating that the form is now working fine, but I can't
>see anything that's changed. If I don't see why the form is now fast, then
>there's no reason to believe that it might not at some point go back to
>being slow again. And then I'd just have to hope that something changes. It
>would be good to figure this out.
>
>Any ideas as to what might have changed here to cause the form's Go To to be
>fast would be appreciated.
Well, there may be lot's of reasons, but I didn't see
anything in your description that ruled out a first time
through delay. The first time you access the recordset may
require a bunch of connection activities to take place.
Another likely cause is that the first search fills the
memory cache so subsequent searches don't have to go back to
the server as often as the it did the first time. To
verify/refute this hypothesis, reboot your system between
each timing test.
Note that you can often avoid all this kind of stuff by
filtering the form's dataset instead of loading all the
records and then searching for the one you want, especially
if the filter field is indexed.
--
Marsh
MVP [MS Access]
Navigation:
[Reply to this message]
|