Form Timer event fails to fire on heavy database access: Access 2003 bug?

[Manuel Lopez]

I have a puzzling form timer problem that I didn't experience prior to
Access 2003 (though I'm not sure access 2003 is to blame).

Here's the situation: a computer has two access 2003 databases on it, a
frontend and a backend.

Case 1: If vba code on the frontend updates many rows (360,000) on the
backend, a form's timer event (from the frontend) will stop firing until the
user gives the form focus. (Note that the update itself always completes
correctly.)

Case 2: If a copy of the entire backend is made to a different computer,
the form's timer event (from the frontend) again stops firing until the user
gives the form focus. (This is an entirely differnet frontend than the one
in case 1. Note that the copy operation itself always completes correctly.)

Despite being reproducible, this is a hard bug to test, because there is no
"crash": the timer event simply seems to stop firing, and the code operates
normally again (the timer event fires again) once the form at issue (or even
the vba code window) gets the focus.

I've tried isolating various hardware culprits (ide drivers etc.), with no
luck. Any suggestions are welcome.

[Salad]

Re: Form Timer event fails to fire on heavy database access: Access2003 bug?

Manuel Lopez wrote:[color=blue]
> I have a puzzling form timer problem that I didn't experience prior to
> Access 2003 (though I'm not sure access 2003 is to blame).
>
> Here's the situation: a computer has two access 2003 databases on it, a
> frontend and a backend.
>
> Case 1: If vba code on the frontend updates many rows (360,000) on the
> backend, a form's timer event (from the frontend) will stop firing until the
> user gives the form focus. (Note that the update itself always completes
> correctly.)
>
> Case 2: If a copy of the entire backend is made to a different computer,
> the form's timer event (from the frontend) again stops firing until the user
> gives the form focus. (This is an entirely differnet frontend than the one
> in case 1. Note that the copy operation itself always completes correctly.)
>
> Despite being reproducible, this is a hard bug to test, because there is no
> "crash": the timer event simply seems to stop firing, and the code operates
> normally again (the timer event fires again) once the form at issue (or even
> the vba code window) gets the focus.
>
> I've tried isolating various hardware culprits (ide drivers etc.), with no
> luck. Any suggestions are welcome.
>[/color]

I have no suggestion as to the "why" but can't you add the command
Docmd.SelectObj ect acForm, "YourFormNa me"
at the end of running the VBA code?

[Tom van Stiphout]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

On Wed, 16 Jun 2004 04:11:03 -0400, "Manuel Lopez"
<manuel.email.a t.post.harvard. edu@deadspam.co m> wrote:

Timer events are among the lowest-priority events. Early on, MSFT
realized they would not be able to guarantee that the event would be
delivered to the message queue EXACTLY every <interval> seconds. So
they did something really smart: tell developers not to rely on its
accurate delivery. They also provided for timer event consolidation,
meaning that if several events should have happened during some
lengthy processing, only 1 event would be in the message queue.

So it is "by design" that the timer doesn't tick during some lengthy
processing.

Workarounds include processing smaller chunks at a time, with a
DoEvents statement in between.

-Tom.

[color=blue]
>I have a puzzling form timer problem that I didn't experience prior to
>Access 2003 (though I'm not sure access 2003 is to blame).
>
>Here's the situation: a computer has two access 2003 databases on it, a
>frontend and a backend.
>
>Case 1: If vba code on the frontend updates many rows (360,000) on the
>backend, a form's timer event (from the frontend) will stop firing until the
>user gives the form focus. (Note that the update itself always completes
>correctly.)
>
>Case 2: If a copy of the entire backend is made to a different computer,
>the form's timer event (from the frontend) again stops firing until the user
>gives the form focus. (This is an entirely differnet frontend than the one
>in case 1. Note that the copy operation itself always completes correctly.)
>
>Despite being reproducible, this is a hard bug to test, because there is no
>"crash": the timer event simply seems to stop firing, and the code operates
>normally again (the timer event fires again) once the form at issue (or even
>the vba code window) gets the focus.
>
>I've tried isolating various hardware culprits (ide drivers etc.), with no
>luck. Any suggestions are welcome.
>
>[/color]

[Manuel Lopez]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

Thanks, but to clarify: the problem is not that some timer events are
SKIPPED, but that the timer STOPS firing, period, FOREVER, until the form
gets focus again.


"Tom van Stiphout" <tom7744@no.spa m.cox.net> wrote in message
news:rcl0d0dc4f faeifvnjbbkbdj3 i4n7vf8tr@4ax.c om...[color=blue]
> On Wed, 16 Jun 2004 04:11:03 -0400, "Manuel Lopez"
> <manuel.email.a t.post.harvard. edu@deadspam.co m> wrote:
>
> Timer events are among the lowest-priority events. Early on, MSFT
> realized they would not be able to guarantee that the event would be
> delivered to the message queue EXACTLY every <interval> seconds. So
> they did something really smart: tell developers not to rely on its
> accurate delivery. They also provided for timer event consolidation,
> meaning that if several events should have happened during some
> lengthy processing, only 1 event would be in the message queue.
>
> So it is "by design" that the timer doesn't tick during some lengthy
> processing.
>
> Workarounds include processing smaller chunks at a time, with a
> DoEvents statement in between.
>
> -Tom.
>
>[color=green]
> >I have a puzzling form timer problem that I didn't experience prior to
> >Access 2003 (though I'm not sure access 2003 is to blame).
> >
> >Here's the situation: a computer has two access 2003 databases on it, a
> >frontend and a backend.
> >
> >Case 1: If vba code on the frontend updates many rows (360,000) on the
> >backend, a form's timer event (from the frontend) will stop firing until[/color][/color]
the[color=blue][color=green]
> >user gives the form focus. (Note that the update itself always completes
> >correctly.)
> >
> >Case 2: If a copy of the entire backend is made to a different computer,
> >the form's timer event (from the frontend) again stops firing until the[/color][/color]
user[color=blue][color=green]
> >gives the form focus. (This is an entirely differnet frontend than the[/color][/color]
one[color=blue][color=green]
> >in case 1. Note that the copy operation itself always completes[/color][/color]
correctly.)[color=blue][color=green]
> >
> >Despite being reproducible, this is a hard bug to test, because there is[/color][/color]
no[color=blue][color=green]
> >"crash": the timer event simply seems to stop firing, and the code[/color][/color]
operates[color=blue][color=green]
> >normally again (the timer event fires again) once the form at issue (or[/color][/color]
even[color=blue][color=green]
> >the vba code window) gets the focus.
> >
> >I've tried isolating various hardware culprits (ide drivers etc.), with[/color][/color]
no[color=blue][color=green]
> >luck. Any suggestions are welcome.
> >
> >[/color]
>[/color]

[Manuel Lopez]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

Catch 22: your code to get the timer event to fire will never run because
the code would have to be in the timer event to do any good. (The form's
having the focus doesn't PREVENT the problem from happening, but when it
receives the focus AFTER the problem, then the timer event resumes firing.)
Of course, I could have another form with another timer event running to
give the focus to the first form, or to call the code at issue directly, but
it all gets very messy and leads to other problems (and I have no guarantee
the second form's timer would run either).
[color=blue]
> I have no suggestion as to the "why" but can't you add the command
> Docmd.SelectObj ect acForm, "YourFormNa me"
> at the end of running the VBA code?[/color]





"Salad" <oil@vinegar.co m> wrote in message
news:3cUzc.6263 $Wr.1092@newsre ad1.news.pas.ea rthlink.net...[color=blue]
> Manuel Lopez wrote:[color=green]
> > I have a puzzling form timer problem that I didn't experience prior to
> > Access 2003 (though I'm not sure access 2003 is to blame).
> >
> > Here's the situation: a computer has two access 2003 databases on it, a
> > frontend and a backend.
> >
> > Case 1: If vba code on the frontend updates many rows (360,000) on the
> > backend, a form's timer event (from the frontend) will stop firing until[/color][/color]
the[color=blue][color=green]
> > user gives the form focus. (Note that the update itself always[/color][/color]
completes[color=blue][color=green]
> > correctly.)
> >
> > Case 2: If a copy of the entire backend is made to a different[/color][/color]
computer,[color=blue][color=green]
> > the form's timer event (from the frontend) again stops firing until the[/color][/color]
user[color=blue][color=green]
> > gives the form focus. (This is an entirely differnet frontend than the[/color][/color]
one[color=blue][color=green]
> > in case 1. Note that the copy operation itself always completes[/color][/color]
correctly.)[color=blue][color=green]
> >
> > Despite being reproducible, this is a hard bug to test, because there is[/color][/color]
no[color=blue][color=green]
> > "crash": the timer event simply seems to stop firing, and the code[/color][/color]
operates[color=blue][color=green]
> > normally again (the timer event fires again) once the form at issue (or[/color][/color]
even[color=blue][color=green]
> > the vba code window) gets the focus.
> >
> > I've tried isolating various hardware culprits (ide drivers etc.), with[/color][/color]
no[color=blue][color=green]
> > luck. Any suggestions are welcome.
> >[/color]
>
> I have no suggestion as to the "why" but can't you add the command
> Docmd.SelectObj ect acForm, "YourFormNa me"
> at the end of running the VBA code?
>[/color]

[Salad]

Re: Form Timer event fails to fire on heavy database access: Access2003 bug?

Manuel Lopez wrote:
[color=blue]
> Catch 22: your code to get the timer event to fire will never run because
> the code would have to be in the timer event to do any good.[/color]

You may be in a catch-22, but my solution handles it. You were talking
about code in the front end to perform some updates. Why would you want
to put my solution in the timer event when you can put it at the end of
the code that performs/initiates the updates?

If my solution won't work then you have not described the problem correctly.


(The form's[color=blue]
> having the focus doesn't PREVENT the problem from happening, but when it
> receives the focus AFTER the problem, then the timer event resumes firing.)
> Of course, I could have another form with another timer event running to
> give the focus to the first form, or to call the code at issue directly, but
> it all gets very messy and leads to other problems (and I have no guarantee
> the second form's timer would run either).
>
>[color=green]
>>I have no suggestion as to the "why" but can't you add the command
>>Docmd.SelectO bject acForm, "YourFormNa me"
>>at the end of running the VBA code?[/color]
>
>
>
>
>
>
> "Salad" <oil@vinegar.co m> wrote in message
> news:3cUzc.6263 $Wr.1092@newsre ad1.news.pas.ea rthlink.net...
>[color=green]
>>Manuel Lopez wrote:
>>[color=darkred]
>>>I have a puzzling form timer problem that I didn't experience prior to
>>>Access 2003 (though I'm not sure access 2003 is to blame).
>>>
>>>Here's the situation: a computer has two access 2003 databases on it, a
>>>frontend and a backend.
>>>
>>>Case 1: If vba code on the frontend updates many rows (360,000) on the
>>>backend, a form's timer event (from the frontend) will stop firing until[/color][/color]
>
> the
>[color=green][color=darkred]
>>>user gives the form focus. (Note that the update itself always[/color][/color]
>
> completes
>[color=green][color=darkred]
>>>correctly. )
>>>
>>>Case 2: If a copy of the entire backend is made to a different[/color][/color]
>
> computer,
>[color=green][color=darkred]
>>>the form's timer event (from the frontend) again stops firing until the[/color][/color]
>
> user
>[color=green][color=darkred]
>>>gives the form focus. (This is an entirely differnet frontend than the[/color][/color]
>
> one
>[color=green][color=darkred]
>>>in case 1. Note that the copy operation itself always completes[/color][/color]
>
> correctly.)
>[color=green][color=darkred]
>>>Despite being reproducible, this is a hard bug to test, because there is[/color][/color]
>
> no
>[color=green][color=darkred]
>>>"crash": the timer event simply seems to stop firing, and the code[/color][/color]
>
> operates
>[color=green][color=darkred]
>>>normally again (the timer event fires again) once the form at issue (or[/color][/color]
>
> even
>[color=green][color=darkred]
>>>the vba code window) gets the focus.
>>>
>>>I've tried isolating various hardware culprits (ide drivers etc.), with[/color][/color]
>
> no
>[color=green][color=darkred]
>>>luck. Any suggestions are welcome.
>>>[/color]
>>
>>I have no suggestion as to the "why" but can't you add the command
>>Docmd.SelectO bject acForm, "YourFormNa me"
>>at the end of running the VBA code?
>>[/color]
>
>
>[/color]

[david epsom dot com dot au]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

I don't have 2003 loaded to test, but on A97, the timer
form gets focus every time a timer event happens. (At little
bit strange if you don't expect it: you can't actually see
the form get focus, but you can feel it happening....)
So I guess the timer is reset when the form gets focus.

(david)


"Tom van Stiphout" <tom7744@no.spa m.cox.net> wrote in message
news:rcl0d0dc4f faeifvnjbbkbdj3 i4n7vf8tr@4ax.c om...[color=blue]
> On Wed, 16 Jun 2004 04:11:03 -0400, "Manuel Lopez"
> <manuel.email.a t.post.harvard. edu@deadspam.co m> wrote:
>
> Timer events are among the lowest-priority events. Early on, MSFT
> realized they would not be able to guarantee that the event would be
> delivered to the message queue EXACTLY every <interval> seconds. So
> they did something really smart: tell developers not to rely on its
> accurate delivery. They also provided for timer event consolidation,
> meaning that if several events should have happened during some
> lengthy processing, only 1 event would be in the message queue.
>
> So it is "by design" that the timer doesn't tick during some lengthy
> processing.
>
> Workarounds include processing smaller chunks at a time, with a
> DoEvents statement in between.
>
> -Tom.
>
>[color=green]
> >I have a puzzling form timer problem that I didn't experience prior to
> >Access 2003 (though I'm not sure access 2003 is to blame).
> >
> >Here's the situation: a computer has two access 2003 databases on it, a
> >frontend and a backend.
> >
> >Case 1: If vba code on the frontend updates many rows (360,000) on the
> >backend, a form's timer event (from the frontend) will stop firing until[/color][/color]
the[color=blue][color=green]
> >user gives the form focus. (Note that the update itself always completes
> >correctly.)
> >
> >Case 2: If a copy of the entire backend is made to a different computer,
> >the form's timer event (from the frontend) again stops firing until the[/color][/color]
user[color=blue][color=green]
> >gives the form focus. (This is an entirely differnet frontend than the[/color][/color]
one[color=blue][color=green]
> >in case 1. Note that the copy operation itself always completes[/color][/color]
correctly.)[color=blue][color=green]
> >
> >Despite being reproducible, this is a hard bug to test, because there is[/color][/color]
no[color=blue][color=green]
> >"crash": the timer event simply seems to stop firing, and the code[/color][/color]
operates[color=blue][color=green]
> >normally again (the timer event fires again) once the form at issue (or[/color][/color]
even[color=blue][color=green]
> >the vba code window) gets the focus.
> >
> >I've tried isolating various hardware culprits (ide drivers etc.), with[/color][/color]
no[color=blue][color=green]
> >luck. Any suggestions are welcome.
> >
> >[/color]
>[/color]

[Tony Toews]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

"Manuel Lopez" <manuel.email.a t.post.harvard. edu@deadspam.co m> wrote:
[color=blue]
>I have a puzzling form timer problem that I didn't experience prior to
>Access 2003 (though I'm not sure access 2003 is to blame).
>
>Here's the situation: a computer has two access 2003 databases on it, a
>frontend and a backend.
>
>Case 1: If vba code on the frontend updates many rows (360,000) on the
>backend, a form's timer event (from the frontend) will stop firing until the
>user gives the form focus. (Note that the update itself always completes
>correctly.)[/color]

What happens if you put a DoEvents in between each recordset update?

Have you tried this in A2002 or A2000 if available to you?
[color=blue]
>Case 2: If a copy of the entire backend is made to a different computer,
>the form's timer event (from the frontend) again stops firing until the user
>gives the form focus. (This is an entirely differnet frontend than the one
>in case 1. Note that the copy operation itself always completes correctly.)[/color]

In A97 I have a hidden form with a timer that kicks users out. It never gets the
focus and yet works fine.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at

http://www.granite.ab.ca/accsmstr.htm

[david epsom dot com dot au]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

> In A97 I have a hidden form with a timer that kicks users out. It never
gets[color=blue]
> focus and yet works fine.[/color]


It is however 'restored' (which can mess up your 'maximized' forms)
on every timer event if it is hidden, and the VBA IDE temporarily
looses focus on every timer event.

(david)

"Tony Toews" <ttoews@teluspl anet.net> wrote in message
news:a304d05hiu sjq7knga0hvrpaj drg18hn4e@4ax.c om...[color=blue]
> "Manuel Lopez" <manuel.email.a t.post.harvard. edu@deadspam.co m> wrote:
>[color=green]
> >I have a puzzling form timer problem that I didn't experience prior to
> >Access 2003 (though I'm not sure access 2003 is to blame).
> >
> >Here's the situation: a computer has two access 2003 databases on it, a
> >frontend and a backend.
> >
> >Case 1: If vba code on the frontend updates many rows (360,000) on the
> >backend, a form's timer event (from the frontend) will stop firing until[/color][/color]
the[color=blue][color=green]
> >user gives the form focus. (Note that the update itself always completes
> >correctly.)[/color]
>
> What happens if you put a DoEvents in between each recordset update?
>
> Have you tried this in A2002 or A2000 if available to you?
>[color=green]
> >Case 2: If a copy of the entire backend is made to a different computer,
> >the form's timer event (from the frontend) again stops firing until the[/color][/color]
user[color=blue][color=green]
> >gives the form focus. (This is an entirely differnet frontend than the[/color][/color]
one[color=blue][color=green]
> >in case 1. Note that the copy operation itself always completes[/color][/color]
correctly.)[color=blue]
>
> In A97 I have a hidden form with a timer that kicks users out. It never[/color]
gets the[color=blue]
> focus and yet works fine.
>
> Tony
> --
> Tony Toews, Microsoft Access MVP
> Please respond only in the newsgroups so that others can
> read the entire thread of messages.
> Microsoft Access Links, Hints, Tips & Accounting Systems at
> http://www.granite.ab.ca/accsmstr.htm[/color]

[Tony Toews]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

"david epsom dot com dot au" <david@epsomdot comdotau> wrote:
[color=blue][color=green]
>> In A97 I have a hidden form with a timer that kicks users out. It never[/color]
>gets[color=green]
>> focus and yet works fine.[/color]
>
>
>It is however 'restored' (which can mess up your 'maximized' forms)
>on every timer event if it is hidden,[/color]

Hmm, I never realized that. That would explain some interesting problems for which
we've always used a work around. Thanks.

"Also print preview would sometimes not allow the users to run a menu item to export
the report to Excel or others. So you had to right click on the Previewed report to
get some type of internal focus back on the report so they could then export it.
This was also helped by extending the timer to five minutes."
[color=blue]
>and the VBA IDE temporarily
>looses focus on every timer event.[/color]

Ayup, and you should be turning timers off when doing VBA stuff anyhow. (Actually I
turn the timer on when the first form loads and it's an MDE.) Otherwise, as I'm sure
you know but lurkers may not, Intellisense gets royally screwed up.

Not sure what that has to do with Manuels problem though.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at

http://www.granite.ab.ca/accsmstr.htm

[Manuel Lopez]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

Sorry, you're absolutely right, my explanation did in fact leave out
something crucial in case #1 (and was unclear in case #2).

In case #1, there are actually at least two processes (two forms in separate
databases accessing the backend), and I was assuming that the "contention "
between the two, heavy drive access to the same database, is what caused the
first process to "die" (i.e. stop firing its timer event): Form A updates
the backend and finishes executing its timer event code; then form B, C, D,
etc. or a user kicks in a few seconds later and also accesses the backend
while changes ordered by form A are being written from cache to the drive;
and this later access, I assumed, is what kills form A's timer code. (In
case #2, there's also contention between two processes, the process making
the copy of the database and the code in the form's timer event.)

But I realize now I don't even know if form A by itself could be responsible
for killing off the timer event, in which case your solution has a chance of
working, IF the cause occurs before the line to give focus is reached. The
vague way I was thinking about it, it was the lengthy disk writing set off
by form A WHEN still executing later (writing from cache to disk) AT THE
TIME the timer event should fire again, is somehow to blame, which would be
AFTER the line to give focus to form A.

I'm glad you brought out those assumptions in my thinking; I'll certainly
test out your suggestion, but it might take me a few days to schedule in an
interruption.

(Also, most of the time, I have no control over when there is heavy disk
access affecting the database, so it would be complicated to ensure any
process causing such access, esp. by the user, also forced all the forms of
the other processes running with timer events to get focus.)


"Salad" <oil@vinegar.co m> wrote in message
news:Zn1Ac.3291 $w07.2381@newsr ead2.news.pas.e arthlink.net...[color=blue]
> Manuel Lopez wrote:
>[color=green]
> > Catch 22: your code to get the timer event to fire will never run[/color][/color]
because[color=blue][color=green]
> > the code would have to be in the timer event to do any good.[/color]
>
> You may be in a catch-22, but my solution handles it. You were talking
> about code in the front end to perform some updates. Why would you want
> to put my solution in the timer event when you can put it at the end of
> the code that performs/initiates the updates?
>
> If my solution won't work then you have not described the problem[/color]
correctly.[color=blue]
>
>
> (The form's[color=green]
> > having the focus doesn't PREVENT the problem from happening, but when it
> > receives the focus AFTER the problem, then the timer event resumes[/color][/color]
firing.)[color=blue][color=green]
> > Of course, I could have another form with another timer event running to
> > give the focus to the first form, or to call the code at issue directly,[/color][/color]
but[color=blue][color=green]
> > it all gets very messy and leads to other problems (and I have no[/color][/color]
guarantee[color=blue][color=green]
> > the second form's timer would run either).
> >
> >[color=darkred]
> >>I have no suggestion as to the "why" but can't you add the command
> >>Docmd.SelectO bject acForm, "YourFormNa me"
> >>at the end of running the VBA code?[/color]
> >
> >
> >
> >
> >
> >
> > "Salad" <oil@vinegar.co m> wrote in message
> > news:3cUzc.6263 $Wr.1092@newsre ad1.news.pas.ea rthlink.net...
> >[color=darkred]
> >>Manuel Lopez wrote:
> >>
> >>>I have a puzzling form timer problem that I didn't experience prior to
> >>>Access 2003 (though I'm not sure access 2003 is to blame).
> >>>
> >>>Here's the situation: a computer has two access 2003 databases on it, a
> >>>frontend and a backend.
> >>>
> >>>Case 1: If vba code on the frontend updates many rows (360,000) on the
> >>>backend, a form's timer event (from the frontend) will stop firing[/color][/color][/color]
until[color=blue][color=green]
> >
> > the
> >[color=darkred]
> >>>user gives the form focus. (Note that the update itself always[/color]
> >
> > completes
> >[color=darkred]
> >>>correctly. )
> >>>
> >>>Case 2: If a copy of the entire backend is made to a different[/color]
> >
> > computer,
> >[color=darkred]
> >>>the form's timer event (from the frontend) again stops firing until the[/color]
> >
> > user
> >[color=darkred]
> >>>gives the form focus. (This is an entirely differnet frontend than the[/color]
> >
> > one
> >[color=darkred]
> >>>in case 1. Note that the copy operation itself always completes[/color]
> >
> > correctly.)
> >[color=darkred]
> >>>Despite being reproducible, this is a hard bug to test, because there[/color][/color][/color]
is[color=blue][color=green]
> >
> > no
> >[color=darkred]
> >>>"crash": the timer event simply seems to stop firing, and the code[/color]
> >
> > operates
> >[color=darkred]
> >>>normally again (the timer event fires again) once the form at issue (or[/color]
> >
> > even
> >[color=darkred]
> >>>the vba code window) gets the focus.
> >>>
> >>>I've tried isolating various hardware culprits (ide drivers etc.), with[/color]
> >
> > no
> >[color=darkred]
> >>>luck. Any suggestions are welcome.
> >>>
> >>
> >>I have no suggestion as to the "why" but can't you add the command
> >>Docmd.SelectO bject acForm, "YourFormNa me"
> >>at the end of running the VBA code?
> >>[/color]
> >
> >
> >[/color]
>[/color]

[Manuel Lopez]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

I didn't see that behavior happen in A97, but you also said you couldn't see
it happen. What do you mean by "feeling" it--you mean the timer event
triggered a focus event but did not actually give any visible focus to the
form? (Re the timer event reset--I did not get a reset in A97, if you mean
that if the timer is set for 1 minute intervals, giving the focus resets it
to waits another minute.)


"david epsom dot com dot au" <david@epsomdot comdotau> wrote in message
news:40d0f3c4$0 $29881$61ce578d @news.syd.swift dsl.com.au...[color=blue]
> I don't have 2003 loaded to test, but on A97, the timer
> form gets focus every time a timer event happens. (At little
> bit strange if you don't expect it: you can't actually see
> the form get focus, but you can feel it happening....)
> So I guess the timer is reset when the form gets focus.
>
> (david)
>
>
> "Tom van Stiphout" <tom7744@no.spa m.cox.net> wrote in message
> news:rcl0d0dc4f faeifvnjbbkbdj3 i4n7vf8tr@4ax.c om...[color=green]
> > On Wed, 16 Jun 2004 04:11:03 -0400, "Manuel Lopez"
> > <manuel.email.a t.post.harvard. edu@deadspam.co m> wrote:
> >
> > Timer events are among the lowest-priority events. Early on, MSFT
> > realized they would not be able to guarantee that the event would be
> > delivered to the message queue EXACTLY every <interval> seconds. So
> > they did something really smart: tell developers not to rely on its
> > accurate delivery. They also provided for timer event consolidation,
> > meaning that if several events should have happened during some
> > lengthy processing, only 1 event would be in the message queue.
> >
> > So it is "by design" that the timer doesn't tick during some lengthy
> > processing.
> >
> > Workarounds include processing smaller chunks at a time, with a
> > DoEvents statement in between.
> >
> > -Tom.
> >
> >[color=darkred]
> > >I have a puzzling form timer problem that I didn't experience prior to
> > >Access 2003 (though I'm not sure access 2003 is to blame).
> > >
> > >Here's the situation: a computer has two access 2003 databases on it, a
> > >frontend and a backend.
> > >
> > >Case 1: If vba code on the frontend updates many rows (360,000) on the
> > >backend, a form's timer event (from the frontend) will stop firing[/color][/color][/color]
until[color=blue]
> the[color=green][color=darkred]
> > >user gives the form focus. (Note that the update itself always[/color][/color][/color]
completes[color=blue][color=green][color=darkred]
> > >correctly.)
> > >
> > >Case 2: If a copy of the entire backend is made to a different[/color][/color][/color]
computer,[color=blue][color=green][color=darkred]
> > >the form's timer event (from the frontend) again stops firing until the[/color][/color]
> user[color=green][color=darkred]
> > >gives the form focus. (This is an entirely differnet frontend than the[/color][/color]
> one[color=green][color=darkred]
> > >in case 1. Note that the copy operation itself always completes[/color][/color]
> correctly.)[color=green][color=darkred]
> > >
> > >Despite being reproducible, this is a hard bug to test, because there[/color][/color][/color]
is[color=blue]
> no[color=green][color=darkred]
> > >"crash": the timer event simply seems to stop firing, and the code[/color][/color]
> operates[color=green][color=darkred]
> > >normally again (the timer event fires again) once the form at issue (or[/color][/color]
> even[color=green][color=darkred]
> > >the vba code window) gets the focus.
> > >
> > >I've tried isolating various hardware culprits (ide drivers etc.), with[/color][/color]
> no[color=green][color=darkred]
> > >luck. Any suggestions are welcome.
> > >
> > >[/color]
> >[/color]
>
>[/color]

[Manuel Lopez]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

> What happens if you put a DoEvents in between each recordset update?
Good point (in another words, it could be the failure of the form to
"breathe" for an extended time that kills the timer event--though still a
bug; of course that implies I might not be able to work around it given one
sufficiently "big" update). I'll give it a try next time I get a chance to
alter the code.
[color=blue]
> Have you tried this in A2002 or A2000 if available to you?[/color]
The problem is definitely not in A2000 or A2002, but there were other
changes that accompained by switch to A2003, so I'm not 100% sure A2003 is
to blame--I had to violate my ideal of making only one minor change at a
time, each separated by ten years of testing and waiting to see if any bugs
appear.).
[color=blue]
> In A97 I have a hidden form with a timer that kicks users out. It never[/color]
gets the[color=blue]
> focus and yet works fine.[/color]
Right, I never had this problem in A97.


"Tony Toews" <ttoews@teluspl anet.net> wrote in message
news:a304d05hiu sjq7knga0hvrpaj drg18hn4e@4ax.c om...[color=blue]
> "Manuel Lopez" <manuel.email.a t.post.harvard. edu@deadspam.co m> wrote:
>[color=green]
> >I have a puzzling form timer problem that I didn't experience prior to
> >Access 2003 (though I'm not sure access 2003 is to blame).
> >
> >Here's the situation: a computer has two access 2003 databases on it, a
> >frontend and a backend.
> >
> >Case 1: If vba code on the frontend updates many rows (360,000) on the
> >backend, a form's timer event (from the frontend) will stop firing until[/color][/color]
the[color=blue][color=green]
> >user gives the form focus. (Note that the update itself always completes
> >correctly.)[/color]
>
> What happens if you put a DoEvents in between each recordset update?
>
> Have you tried this in A2002 or A2000 if available to you?
>[color=green]
> >Case 2: If a copy of the entire backend is made to a different computer,
> >the form's timer event (from the frontend) again stops firing until the[/color][/color]
user[color=blue][color=green]
> >gives the form focus. (This is an entirely differnet frontend than the[/color][/color]
one[color=blue][color=green]
> >in case 1. Note that the copy operation itself always completes[/color][/color]
correctly.)[color=blue]
>
> In A97 I have a hidden form with a timer that kicks users out. It never[/color]
gets the[color=blue]
> focus and yet works fine.
>
> Tony
> --
> Tony Toews, Microsoft Access MVP
> Please respond only in the newsgroups so that others can
> read the entire thread of messages.
> Microsoft Access Links, Hints, Tips & Accounting Systems at
> http://www.granite.ab.ca/accsmstr.htm[/color]

[Tony Toews]

Re: Form Timer event fails to fire on heavy database access: Access 2003 bug?

"Manuel Lopez" <manuel.email.a t.post.harvard. edu@deadspam.co m> wrote:
[color=blue]
>I had to violate my ideal of making only one minor change at a
>time, each separated by ten years of testing and waiting to see if any bugs
>appear.).[/color]

<chuckle>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at

http://www.granite.ab.ca/accsmstr.htm