Form Timer事件无法在大量数据库访问时触发：Access 2003错误？ [英] Form Timer event fails to fire on heavy database access: Access 2003 bug?

问题描述

我有一个令人费解的形式计时器问题，我之前没有经历过

Access 2003（虽然我不确定访问2003是否应该受到责备）。


这就是这样的情况：计算机上有两个访问2003数据库，一个

前端和一个后端。


案例1：如果前端的vba代码在

后端更新了很多行（360,000），表单'的计时器事件（来自前端）将停止触发，直到

用户给出表单焦点。 （请注意，更新本身始终正确完成

。）


案例2：如果将整个后端的副本发送到另一台计算机，则

表单的'计时器事件（来自前端）再次停止触发，直到用户

给出表单焦点。 （这是完全不同的前端而不是案例1中的一个

。请注意，复制操作本身总是正确完成。）


尽管可重现，但这是一个难以测试的bug，因为没有

崩溃：计时器事件似乎只是停止触发，并且代码通常会再次运行
（计时器）事件再次触发）一旦有问题的表格（甚至是vba代码窗口的
）得到了关注。


我试过隔离各种硬件罪魁祸首（ide司机等），没有

运气。欢迎任何建议。

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写道：

Manuel Lopez wrote:

我有一个令人费解的形式计时器问题，我在访问2003之前没有经历过（虽然我不确定访问2003是否应该受到责备）。

这里的情况是：一台计算机有两个访问权限2003它上面的数据库，一个前端和一个后端。

案例1：如果前端的vba代码在
后端更新了很多行（360,000），那么表单''计时器事件（从前端）将停止射击，直到
用户给出表格焦点。 （请注意，更新本身始终正确完成。）

案例2：如果将整个后端的副本发送到另一台计算机，则表单''的计时器事件（从前端）再次停止射击，直到用户
给出表格焦点。 （这是一个完全不同的前端而不是案例1中的那个。请注意，复制操作本身总是正确完成。）

尽管可重现，但这是一个难以测试的错误，因为没有
崩溃：计时器事件似乎只是停止触发，并且代码正常运行
（一旦有问题的表格再次触发计时器事件）（甚至
vba代码窗口获得了关注。

我已经尝试隔离各种硬件元凶（ide驱动程序等），没有运气。欢迎任何建议。

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.

我没有关于为什么的建议。但是你不能在运行VBA代码结束时添加命令

Docmd.SelectObject acForm，YourFormName

？

2004年6月16日星期三04:11:03 -0400，Manuel Lopez

< ma ******** **********************@deadspam.com>写道：


定时器事件属于优先级最低的事件。在早期，MSFT

意识到他们无法保证每次< interval>的事件将被传送到消息队列中。秒。所以

他们做了一些非常聪明的事情：告诉开发人员不要依赖它的准确交付。他们还提供了计时器事件合并，

意味着如果在某些

冗长处理期间发生了多个事件，则只有1个事件将在消息队列中。


所以它是按设计在一些漫长的

处理期间，计时器不会打勾。


解决方法包括一次处理较小的块，

之间的DoEvents声明。


-Tom。

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.

我有一个令人费解的形式定时器问题，我没有''在访问Access 2003之前的体验（虽然我不确定访问2003是否应该受到责备）。

这里的情况是：计算机上有两个访问2003数据库，一个
前端和后端。

案例1：如果前端的vba代码在
后端更新了许多行（360,000），那么表单的计时器事件（来自前端）将停止射击，直到
用户给出表格焦点。 （请注意，更新本身始终正确完成。）

案例2：如果将整个后端的副本发送到另一台计算机，则表单''的计时器事件（从前端）再次停止射击，直到用户
给出表格焦点。 （这是一个完全不同的前端而不是案例1中的那个。请注意，复制操作本身总是正确完成。）

尽管可重现，但这是一个难以测试的错误，因为没有
崩溃：计时器事件似乎只是停止触发，并且代码正常运行
（一旦有问题的表格再次触发计时器事件）（甚至
vba代码窗口获得了关注。

我已经尝试隔离各种硬件元凶（ide驱动程序等），没有运气。欢迎任何建议。

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.

谢谢，但要澄清：问题不在于某些计时器事件是

SKIPPED，但计时器STOPS解雇，期间，FOREVER，直到形式

再次获得焦点。

Tom van Stiphout <到***** @ no.spam.cox.net>在消息中写道

news：rc ******************************** @ 4ax.com ...

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

2004年6月16日星期三04:11:03 -0400，Manuel Lopez
< ma ************* *****************@deadspam.com>写道：

计时器事件是优先级最低的事件之一。早期，MSFT意识到他们无法保证事件将在每个< interval>中完全传递到消息队列。秒。所以他们做了一些非常聪明的事情：告诉开发人员不要依赖它准确的交付。他们还提供了计时器事件合并，这意味着如果在一些漫长的处理过程中发生了几个事件，那么只有一个事件会在消息队列中。

所以它是按设计计时器在一些冗长的处理过程中不会打勾。

解决方法包括一次处理较小的块，其间有一个
DoEvents语句。
< brom>

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.

我有一个令人费解的表单计时器问题，我在访问2003之前没有遇到过（虽然我是不确定访问2003是否应该受到责备。

以下是这种情况：计算机上有两个访问2003数据库，一个
前端和一个后端。
后端更新了许多行（360,000），则表单'的计时器事件（来自前端）将停止触发，直到
用户提供表单焦点。 （请注意，更新本身始终正确完成。）

案例2：如果将整个后端的副本发送到另一台计算机，则表单''的计时器event（从前端）再次停止触发，直到
用户授予表单焦点。 （这是一个完全不同的前端而不是
onein case 1.请注意，复制操作本身总是正确地完成
。）
尽管可重现，但这是一个难以测试的bug，因为那里是
没有崩溃：计时器事件似乎只是停止触发，并且代码
再次正常运行（计时器事件再次触发）一旦有问题的表格（或
事件发生在vba代码窗口）获得焦点。

我已经尝试用
noluck来隔离各种硬件元凶（ide驱动程序等）。欢迎任何建议。

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.

这篇关于Form Timer事件无法在大量数据库访问时触发：Access 2003错误？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！