Form Slow, Then Fast

**John Bell** · Oct 16 '05, 07:35 PM

Re: Form Slow, Then Fast

Hi

Could anyone (or a job) be affecting the backend?

John

"Neil" <nospam@nospam. net> wrote in message
news:WAx4f.4073 $hY6.455@newsre ad1.news.pas.ea rthlink.net...[color=blue]
>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.RecordsetClo ne
> .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.
>
> Thanks,
>
> Neil
>[/color]

**Marshall Barton** · Oct 16 '05, 07:55 PM

Re: Form Slow, Then Fast

Neil wrote:
[color=blue]
>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.RecordsetClo ne
> .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.[/color]

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]

**Steve Jorgensen** · Oct 16 '05, 08:05 PM

Re: Form Slow, Then Fast

The problem might actually be your combo box. The combo box holds locks on
the server side until its last record has been read. If you go to the last
row in the combo box (or ask for its list count in code) the locks are
released. If you don't access slowly populates list items in the background,
and can take a very long time to complete, even if the number of rows is
small, but especially if it is large.

On Sun, 16 Oct 2005 19:10:46 GMT, "Neil" <nospam@nospam. net> wrote:
[color=blue]
>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.RecordsetClo ne
> .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.
>
>Thanks,
>
>Neil
>[/color]

**Neil** · Oct 16 '05, 08:05 PM

Re: Form Slow, Then Fast

No, I've tried it too many times and at too many different times of day for
it to be environmental. The results are always the same: the old version of
the form takes 20-25 seconds to go to record 100, and it takes 1-2 seconds
to go to record 50,000 (with records between those two varying in times
proportionally) ; the new version of the form takes 1-2 seconds to go to any
record, even though I didn't explicitly change anything, and I cannot find
any differences between the two forms.

N

"John Bell" <jbellnewsposts @hotmail.com> wrote in message
news:4352a9b5$0 $21931$db0fefd9 @news.zen.co.uk ...[color=blue]
> Hi
>
> Could anyone (or a job) be affecting the backend?
>
> John
>
> "Neil" <nospam@nospam. net> wrote in message
> news:WAx4f.4073 $hY6.455@newsre ad1.news.pas.ea rthlink.net...[color=green]
>>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.RecordsetClo ne
>> .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.
>>
>> Thanks,
>>
>> Neil
>>[/color]
>
>[/color]

**Neil** · Oct 16 '05, 08:15 PM

Re: Form Slow, Then Fast

[color=blue]
> 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.[/color]

Yes, I should have mentioned that I did these tests repeatedly to rule that
out: go to record 100 (very slow); then manually move back to the first
record; then go to record 100 (still very slow); then back to the first
record; then go to record 50,000 (very fast); then back to the first record;
then go to record 100 (very slow); etc.

I should have noted that. Sorry.
[color=blue]
> 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.[/color]

How would that explain why it's very fast when going to a record at the end
of the set?
[color=blue]
>
> 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.[/color]

Yes, indeed. This is something the client wants, though, as they like being
able to switch back and forth between form view and datasheet view.
Otherwise, yes, that would be a better way to go.

Thanks,

N
[color=blue]
>
> --
> Marsh
> MVP [MS Access][/color]

**Neil** · Oct 16 '05, 08:25 PM

Re: Form Slow, Then Fast

"Steve Jorgensen" <nospam@nospam. nospam> wrote in message
news:efc5l11ce6 uhrccnbvj175duf 936us2nac@4ax.c om...[color=blue]
> The problem might actually be your combo box. The combo box holds locks
> on
> the server side until its last record has been read. If you go to the
> last
> row in the combo box (or ask for its list count in code) the locks are
> released.[/color]

Well, I think you've hit the nail on the head. I tried it with a text box,
and the problem wasn't there. That also explains the last-fast-first-slow
phenomenon, which I found very puzzling. Thanks! (I have to admit that I
posted this sort of like a message in a bottle, without much hope that
anything would come from it. Needless to say, I'm overjoyed here.)
[color=blue]
> If you don't access slowly populates list items in the background,
> and can take a very long time to complete, even if the number of rows is
> small, but especially if it is large.[/color]

I think you forgot a noun or a verb in the above, so I don't really
understand what you're saying. Could you rephrase it?

I'll just note that I didn't consider the combo boxes because the two forms
were identical, and I didn't recall changing anything there. So when I
compared the two forms, I only compared the code modules and the form
properties. I didn't examine the combo box properties.

However, in light of the above, I took a closer look at the combo boxes,
since, even though your explanation makes sense, it doesn't explain why go
to's are always fast on the new version of the form, even with the combo box
there. So I took a look at the two combo boxes, and, on the new version of
the form, where there's no problem, that combo box is *not* set to limit to
list, whereas the original one was. (I must have changed it as I was working
with the form.) So, apparently, that's the difference.

To confirm this, I went into the new version of the form, set the combo to
limit to list, and, voila!, it was slow like the other. Then I changed it
back to not limit to list, and it was fast again.

So I'm relieved to know that it's not a gremlin that's causing this.

Thanks again for your help.

Neil

[color=blue]
>
> On Sun, 16 Oct 2005 19:10:46 GMT, "Neil" <nospam@nospam. net> wrote:
>[color=green]
>>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.RecordsetClo ne
>> .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.
>>
>>Thanks,
>>
>>Neil
>>[/color]
>[/color]

**Steve Jorgensen** · Oct 16 '05, 08:35 PM

Re: Form Slow, Then Fast

On Sun, 16 Oct 2005 20:19:38 GMT, "Neil" <nospam@nospam. net> wrote:
[color=blue]
>
>"Steve Jorgensen" <nospam@nospam. nospam> wrote in message
>news:efc5l11ce 6uhrccnbvj175du f936us2nac@4ax. com...[color=green]
>> The problem might actually be your combo box. The combo box holds locks
>> on
>> the server side until its last record has been read. If you go to the
>> last
>> row in the combo box (or ask for its list count in code) the locks are
>> released.[/color]
>
>Well, I think you've hit the nail on the head. I tried it with a text box,
>and the problem wasn't there. That also explains the last-fast-first-slow
>phenomenon, which I found very puzzling. Thanks! (I have to admit that I
>posted this sort of like a message in a bottle, without much hope that
>anything would come from it. Needless to say, I'm overjoyed here.)
>[color=green]
>> If you don't access slowly populates list items in the background,
>> and can take a very long time to complete, even if the number of rows is
>> small, but especially if it is large.[/color]
>
>I think you forgot a noun or a verb in the above, so I don't really
>understand what you're saying. Could you rephrase it?[/color]

I was missing a comma. To rephrase... If you don't read the whole list by
selecting the last row in the combo box or by getting its list count, Access
will slowly retrieve the combo box rows in the background, it may take a very
long time, and some locks will be held for duration. Locks can be held for a
long time even by combo boxes with fairly few rows.
[color=blue]
>
>I'll just note that I didn't consider the combo boxes because the two forms
>were identical, and I didn't recall changing anything there. So when I
>compared the two forms, I only compared the code modules and the form
>properties. I didn't examine the combo box properties.
>
>However, in light of the above, I took a closer look at the combo boxes,
>since, even though your explanation makes sense, it doesn't explain why go
>to's are always fast on the new version of the form, even with the combo box
>there. So I took a look at the two combo boxes, and, on the new version of
>the form, where there's no problem, that combo box is *not* set to limit to
>list, whereas the original one was. (I must have changed it as I was working
>with the form.) So, apparently, that's the difference.
>
>To confirm this, I went into the new version of the form, set the combo to
>limit to list, and, voila!, it was slow like the other. Then I changed it
>back to not limit to list, and it was fast again.
>
>So I'm relieved to know that it's not a gremlin that's causing this.
>
>Thanks again for your help.
>
>Neil
>
>[color=green]
>>
>> On Sun, 16 Oct 2005 19:10:46 GMT, "Neil" <nospam@nospam. net> wrote:
>>[color=darkred]
>>>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.RecordsetClo ne
>>> .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
>>>difference s. 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.
>>>
>>>Thanks,
>>>
>>>Neil
>>>[/color]
>>[/color]
>[/color]

**Neil** · Oct 16 '05, 08:45 PM

Re: Form Slow, Then Fast

>>> If you don't access slowly populates list items in the background,[color=blue][color=green][color=darkred]
>>> and can take a very long time to complete, even if the number of rows is
>>> small, but especially if it is large.[/color]
>>
>>I think you forgot a noun or a verb in the above, so I don't really
>>understand what you're saying. Could you rephrase it?[/color]
>
> I was missing a comma. To rephrase... If you don't read the whole list by
> selecting the last row in the combo box or by getting its list count,
> Access
> will slowly retrieve the combo box rows in the background, it may take a
> very
> long time, and some locks will be held for duration. Locks can be held
> for a
> long time even by combo boxes with fairly few rows.[/color]

Right. (Isn't it fun working with a product like Access whose name can be a
noun or a verb? :-) )

What's strange, though, is that it happened multiple times. You'd think that
after the combo box went to the last record (and a resulting fast go to),
that it would have the list in cache and subsequent go to's would be fast.
But each time it was slow, even one right after the other.

Also, another interesting point is how the limit to list was the pivital
feature. You would think that, whether limit to list was set or not, that
Access would still need to populate the whole list, so the results would be
the same. I guess it has to cross-check the list with limit to list, so
maybe that's the difference.

N

[color=blue]
>[color=green]
>>
>>I'll just note that I didn't consider the combo boxes because the two
>>forms
>>were identical, and I didn't recall changing anything there. So when I
>>compared the two forms, I only compared the code modules and the form
>>properties. I didn't examine the combo box properties.
>>
>>However, in light of the above, I took a closer look at the combo boxes,
>>since, even though your explanation makes sense, it doesn't explain why go
>>to's are always fast on the new version of the form, even with the combo
>>box
>>there. So I took a look at the two combo boxes, and, on the new version of
>>the form, where there's no problem, that combo box is *not* set to limit
>>to
>>list, whereas the original one was. (I must have changed it as I was
>>working
>>with the form.) So, apparently, that's the difference.
>>
>>To confirm this, I went into the new version of the form, set the combo to
>>limit to list, and, voila!, it was slow like the other. Then I changed it
>>back to not limit to list, and it was fast again.
>>
>>So I'm relieved to know that it's not a gremlin that's causing this.
>>
>>Thanks again for your help.
>>
>>Neil
>>
>>[color=darkred]
>>>
>>> On Sun, 16 Oct 2005 19:10:46 GMT, "Neil" <nospam@nospam. net> 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.RecordsetClo ne
>>>> .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
>>>>.FindFirs t 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.
>>>>
>>>>Previousl y, 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
>>>>recompile d, 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.
>>>>
>>>>Thanks,
>>>>
>>>>Neil
>>>>
>>>[/color]
>>[/color]
>[/color]

Form Slow, Then Fast

Form Slow, Then Fast

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment