Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

* * * OnTimer event may be the cause of your pain! * * *

122 views
Skip to first unread message

pemigh

unread,
May 18, 2012, 11:44:31 PM5/18/12
to
I have a huge project that has turned into a debugging disaster. Errors are multiple and inconsistent, I am (or was??) baffled, client is furious.

Erorrs include:
2162: A macro set to one of the current field’s properties failed because of an error in a FindRecord action argument.
3420: Object invalid or no longer set ... (everybody's favorite vague error)
3162: You tried to assign a null value ...
3001: Invalid argument ...

The 2162 error occurred inconsistently on a super simple bit of "Docmd.findrecord" code.

Spending my Friday night digging around the internet seeking enlightenment I just happened to spot "Form Timer events are notorious for causing debugging problems (and other problems) but it is often focus issues as well" embedded in http://www.utteraccess.com/forum/Runtime-error-VBA-bre-t365359.html&p=367686

Whoa -- the timer event? I added a timer event a while back!

Experiments ensued. I can't say for certain, since the problem is inconsistent, but the error occurs within a half dozen tries when the timer event is utilized, and I cannot make it appear with dozens and dozens of tries when there is no timer event.

It remains to be seen how many of the problems will be solved, but I'll bet good money that eliminating the timer event will make the "object invalid or no longer set" error evaporate into thin air.

I decided to go ahead and post this since it could potentially solve so many problems out there. Of course, many designers who have searched and searched for soluntions will have given up before they spot this.

Are there other Event Bombs out there, looking all useful and helpful when really all they do is make a wreck of your whole project? (That is such a dainty way of saying what is really on my mind, Microsoft!)

Stay tuned for more....

pemigh

Access Developer

unread,
May 20, 2012, 12:48:23 AM5/20/12
to
Your experience is consistent with my observations over the years (since
1992 when Access 1.0 was released) -- the timer event can be problematical,
especially when trying to debug a database that uses the timer, but in
normal use, too. It is not _always_ a problem, but frequently enough that I
always try to find an alternative approach to solving whatever problem I'd
use timer to address.

The only other events that seem frequently "quirky" to me are the Got Focus
and Lost Focus. They may, in fact, be consistent in operation and just not
operate as I expect.

--
Larry Linson
Microsoft Office Access MVP
Co-Author, Microsoft Access Small Business Solutions, Wiley 2010

"pemigh" <pem...@gmail.com> wrote in message
news:7ffad526-2159-4dea...@googlegroups.com...

Tony Toews

unread,
May 20, 2012, 9:13:12 PM5/20/12
to
On Fri, 18 May 2012 20:44:31 -0700 (PDT), pemigh <pem...@gmail.com>
wrote:

>Spending my Friday night digging around the internet seeking enlightenment I just happened to spot "Form Timer events are notorious for causing debugging problems (and other problems) but it is often focus issues as well" embedded in http://www.utteraccess.com/forum/Runtime-error-VBA-bre-t365359.html&p=367686
>
>Whoa -- the timer event? I added a timer event a while back!

The timer event can certainly cause problems while us programmers are
programming away. As I always ship my front ends as MDEs/ACCDEs I
only turn the timer event on if an MDE is detected.

And yes it can cause focus events but I can't say we saw a lot of
that. One minor problem yes but then in the app I used that in I only
had the timer run every five minutes.

>I decided to go ahead and post this since it could potentially solve so many problems out there. Of course, many designers who have searched and searched for soluntions will have given up before they spot this.

Thanks for the posting.

>Are there other Event Bombs out there, looking all useful and helpful when really all they do is make a wreck of your whole project? (That is such a dainty way of saying what is really on my mind, Microsoft!)

Can't think of any but then I've become so accustomed to the quirks
I've forgetting what are now quirks. <smile>

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

pemigh

unread,
May 21, 2012, 9:58:53 PM5/21/12
to
First day of work with the timer event nixed: Just three errors all day! One 7787 and two 3001.

For the record: On Sunday night I decided to at least temporarily address speed issues by archiving about 60% of the data in the two big where-the-action-is tables. Frisky performance and (almost) no errors leaves users very, very happy.

Now, could Larry or Tony please return the favor of this post by telling me whether there is a way to capture what line of code was running (if any) when data errors occur?

pemigh

pemigh

unread,
May 21, 2012, 10:08:05 PM5/21/12
to
No, wait, I want more.

I want you to convince the Knowledge Base gatekeepers to post articles with titles along the lines of "OnTimer event may cause error xxxx" -- one for each of the errors, so that frustrated users can scan titles only and find what they need.

Truly, this issue is no joke. My client was starting to talk about taking legal action if I could not resolve the problem.

Access Developer

unread,
May 22, 2012, 12:28:00 AM5/22/12
to
Easiest way is to, in design view (Now, whee!, called "backstage view" --
how cute is that? You know, it's difficult for me to realize that they pay
people in Redmond good money to come up with silliness like that.) choose
Options (unless they've renamed that feature, as well) and find and set
"Break on all errors". Then when you encounter the error, it will stop on an
instruction.

--
Larry Linson
Microsoft Office Access MVP
Co-Author, Microsoft Access Small Business Solutions, Wiley 2010

"pemigh" <pem...@gmail.com> wrote in message
news:ef369494-4b2b-4e09...@googlegroups.com...

Tony Toews

unread,
May 22, 2012, 12:51:24 AM5/22/12
to
On Mon, 21 May 2012 18:58:53 -0700 (PDT), pemigh <pem...@gmail.com>
wrote:

>Now, could Larry or Tony please return the favor of this post by telling me whether there is a way to capture what line of code was running (if any) when data errors occur?

If you don't want to interrupt the users then use MzTools for VBA to
create line numbers in the VBA modules of interest. Then in your
error handling routine log err.number, err.description and Erl (error
line number) to a database table. Along with the module name which
MZTools will happily help you to hard code in the module if you use
it's default error handler.

Tony Toews

unread,
May 22, 2012, 12:52:57 AM5/22/12
to
On Mon, 21 May 2012 19:08:05 -0700 (PDT), pemigh <pem...@gmail.com>
wrote:

>No, wait, I want more.
>
>I want you to convince the Knowledge Base gatekeepers to post articles with titles along the lines of "OnTimer event may cause error xxxx" -- one for each of the errors, so that frustrated users can scan titles only and find what they need.
>
>Truly, this issue is no joke. My client was starting to talk about taking legal action if I could not resolve the problem.

Regretfully MVPs have a small amount of influence in their product
group. Maybe. And virtually no influence elsewhere.

Also I hadn't heard of some of these errors happening because on the
Timer event.

Access Developer

unread,
May 22, 2012, 2:02:25 AM5/22/12
to
If I were the one who had to make a decision to invest a significant amount
of time and effort to do what you want were mine, I would be reluctant to do
so for a number of reasons. (Fortunately or unfortunately, I am far removed
from having such responsibility.)

(1) MVPs have little, if any influence, as to what goes in the Knowledge
Base; (2) It seems to me that there has been ample warning for years about
unexpected results when using the Timer; and (3) to try to determine a
complete list of all the errors that might result from a timer event
interrupting other, undefined code would be a massive undertaking.

I can only pass the information on to someone in Redmond that "the timer is
still rearing its ugly head" but, I caution that I have no confidence that
it will result in any action.

The earlier advice to never turn the timer on unless it is an MDE or ACCDE,
and to release those only for production copies of the database is the best
you are likely to get. Though, I think my advice to avoid use of the timer
if there is _any_ other way to accomplish the purpose may even be better.

--
Larry Linson
Microsoft Office Access MVP
Co-Author, Microsoft Access Small Business Solutions, Wiley 2010

"pemigh" <pem...@gmail.com> wrote in message
news:a8fc16be-f58e-4556...@googlegroups.com...

pemigh

unread,
May 23, 2012, 8:43:29 AM5/23/12
to
I need something that will work on a runtime application.

If there is such a tool, it probably relates to numbered code lines. Thought I'd seen something about line numbers in VBA years ago, but I can't find it.

pemigh

Access Developer

unread,
May 24, 2012, 4:45:55 PM5/24/12
to
Searching with BING, using "error linenumber vba" turns up a couple of
direct references:

http://www.fmsinc.com/free/NewTips/VBA/ErrorHandling/LineNumber.html

www.fmsinc.com/tpapers/vbacode/Debug.asp

The freely-downloadable MZTOOLS package includes a line-numbering feature.
I've used this package extensively with Access 2003 and earlier versions (I
don't use Access 2007 or Access 2010 for "real work", only for demos.) It's
described at:

http://www.mztools.com/v3/features.aspx

--
Larry Linson
Microsoft Office Access MVP
Co-Author, Microsoft Access Small Business Solutions, Wiley 2010

"pemigh" <pem...@gmail.com> wrote in message
news:fff2d9c7-a9fc-4a98...@googlegroups.com...
0 new messages