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]

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 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.

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

[Tom van Stiphout]

On Wed, 16 Jun 2004 04:11:03 -0400, "Manuel Lopez"
<ma******************************@deadspam.com> 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.

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.

[Manuel Lopez]

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" <to*****@no.spam.cox.net> wrote in message
news:rc********************************@4ax.com...

On Wed, 16 Jun 2004 04:11:03 -0400, "Manuel Lopez"
<ma******************************@deadspam.com> 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.

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 theuser 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 usergives the form focus. (This is an entirely differnet frontend than the onein 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 operatesnormally again (the timer event fires again) once the form at issue (or eventhe vba code window) gets the focus.

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

[Manuel Lopez]

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).

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


"Salad" <oi*@vinegar.com> wrote in message
news:3c****************@newsread1.news.pas.earthli nk.net... 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 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.

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

[Salad]

Manuel Lopez wrote:

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.
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 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).

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

"Salad" <oi*@vinegar.com> wrote in message
news:3c****************@newsread1.news.pas.earthli nk.net...

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 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.

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

[david epsom dot com dot au]

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" <to*****@no.spam.cox.net> wrote in message
news:rc********************************@4ax.com...

On Wed, 16 Jun 2004 04:11:03 -0400, "Manuel Lopez"
<ma******************************@deadspam.com> 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.

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 theuser 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 usergives the form focus. (This is an entirely differnet frontend than the onein 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 operatesnormally again (the timer event fires again) once the form at issue (or eventhe vba code window) gets the focus.

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

[Tony Toews]

"Manuel Lopez" <ma******************************@deadspam.com> 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 until the
user gives the form focus. (Note that the update itself always completes
correctly.)
What happens if you put a DoEvents in between each recordset update?

Have you tried this in A2002 or A2000 if available to you?
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.)

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]

> In A97 I have a hidden form with a timer that kicks users out. It never
gets

focus and yet works fine.

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" <tt****@telusplanet.net> wrote in message
news:a3********************************@4ax.com... "Manuel Lopez" <ma******************************@deadspam.com> 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 until theuser gives the form focus. (Note that the update itself always completes
correctly.)
What happens if you put a DoEvents in between each recordset update?

Have you tried this in A2002 or A2000 if available to you?

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 usergives the form focus. (This is an entirely differnet frontend than the onein case 1. Note that the copy operation itself always completes

correctly.)
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

[Tony Toews]

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote:

In A97 I have a hidden form with a timer that kicks users out. It nevergets

focus and yet works fine.

It is however 'restored' (which can mess up your 'maximized' forms)
on every timer event if it is hidden,

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."
and the VBA IDE temporarily
looses focus on every timer event.

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]

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" <oi*@vinegar.com> wrote in message
news:Zn*****************@newsread2.news.pas.earthl ink.net...

Manuel Lopez wrote:

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.
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

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).

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

"Salad" <oi*@vinegar.com> wrote in message
news:3c****************@newsread1.news.pas.earthli nk.net...

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

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.
I have no suggestion as to the "why" but can't you add the command
Docmd.SelectObject acForm, "YourFormName"
at the end of running the VBA code?

[Manuel Lopez]

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@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

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" <to*****@no.spam.cox.net> wrote in message
news:rc********************************@4ax.com...

On Wed, 16 Jun 2004 04:11:03 -0400, "Manuel Lopez"
<ma******************************@deadspam.com> 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.

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

completescorrectly.)

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

usergives the form focus. (This is an entirely differnet frontend than the onein 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 operatesnormally again (the timer event fires again) once the form at issue (or eventhe vba code window) gets the focus.

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

[Manuel Lopez]

> 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.

Have you tried this in A2002 or A2000 if available to you? 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.).
In A97 I have a hidden form with a timer that kicks users out. It never gets the focus and yet works fine. Right, I never had this problem in A97.
"Tony Toews" <tt****@telusplanet.net> wrote in message
news:a3********************************@4ax.com... "Manuel Lopez" <ma******************************@deadspam.com> 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 until theuser gives the form focus. (Note that the update itself always completes
correctly.)
What happens if you put a DoEvents in between each recordset update?

Have you tried this in A2002 or A2000 if available to you?

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 usergives the form focus. (This is an entirely differnet frontend than the onein case 1. Note that the copy operation itself always completes

correctly.)
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

[Tony Toews]

"Manuel Lopez" <ma******************************@deadspam.com> wrote:

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.).

<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