One computer in a network won't respond to an OnTimer Event

[MacroScope]

I've got an SQL Server network with about 20 users running Access 2007. When the database opens a hidden form opens with Autoexec that has a timer interval of 60000 and OnTimer it runs a macro that checks several things on each work station once a minute. For example, if certain parameters are met messages pop, and other things are checked as well. This system works very well on 19 stations. On one, however it only runs once, and then just doesn't run again. That station runs Windows 7, but probably half of the stations on the network use Win 7 as well, so I can't attribute it to the OS.

I don't understand what could stop a simple OnTimer event from running. I put a MsgBox as the first step so it would display every time it ran for test purposes, and the box pops once, sometimes twice, and then simply doesn't run again. I've used the Immediate Window to read the TimerInterval for the form while it's not working, thinking somehow it's changing, but it's not. It remains at 60000, even though the OnTimer event is being ignored. The OnTimer event remains unchanged as well, not that I had any reason to suspect otherwise.

Is there any particular reason anyone can imagine why something so straightforward wouldn't work on only one station?

 

[TheAceMan1]

How are ya MacroScope . . .

Sounds like corruption to me.

[ul]
[li]Rename the hidden form.[/li]
[li]Instantiate a new hidden form with the proper name and timer coding.[/li]
[li]Perform your testing.[/li]
[/ul]

Your Thoughts?

See Ya! . . . . . .

Be sure to see faq219-2884 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]

 

[lameid]

I agree that it is likely corruption...

I'd copy the front-end from a known good source and be done with it.

Otherwise I'd use the command line decompile switch followed by a compact-repair followed by compiling all code to see if that does it as my first steps as this usually ends up fixing any code/compile issues I have.

It should go without saying but do all your machines have the same patches for Access? And to start reaching for the kitchen sink... Same Windows patches? Same Security software? Is the Bios fully patched on the system? In pure desperation I might go as far as swapping the HD to a PC in an identical PC that works... At least then you would know for 100% that it is or is not hardware related (doubtful but we all get lucky from time to time).

 

[MacroScope]

All work I do on the database is done on a copy (call it Frontend2) that resides on the P:\ drive (public drive). When I'm finished working, I delete the Frontend copy that resides in the same directory, copy and paste Frontend2 back to the same folder, and then rename the copy to be Frontend, thereby transferring all updates to a new file with the same name as the original. By the way, I always run Compact and Repair before the copy/paste/rename operations I mentioned so that the copy is always fully compacted, even if I don't work on it for months.

Each work station runs a script on login that goes back to the P:\ drive and brings a copy of that file to the local C:\ drive for use.

The point is that everyone's C:\ copy is identical to each other on login, which in my mind eliminates local corruption as a possibility.

lameid, I think that your idea of swapping the hd to another machine would be a valid test just to see what is going on, and I thank you for the suggestion.

Ace, given my explanation above, do you still see any value in renaming the form, etc? I don't see how it could make any difference.

 

[TheAceMan1]

MacroScope . . .

Quick & dirty ... what happens if you overwrite the [blue]bad frontend db[/blue] with a copy of a frontend that works? If this fails, we need to see the code in the OnTimer event.

See Ya! . . . . . .

Be sure to see faq219-2884 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]

 

[MacroScope]

I guess my point is that there's no such thing as a bad frontend copy. There's only one copy, and everyone's replacing their C: drive copy with a fresh copy of the same database every time they log in.

The OnTimer event is a macro, and I am certain that the macro itself is not at fault for two reasons. One, it works just fine on 19 other stations, and two, I replaced the very first event run by that macro with a message box so that when it ran it would be visible. It simply didn't run.

This has been frustrating for me because it just doesn't make sense!

 

[PHV]

Are you sure the Autoexec macro runs on that PC ?
Are the global settings of msaccess the very same on all PC ?

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[MacroScope]

Yes. There are several things that run with AutoExec, other forms that open, etc, and they all work. I use the Immediate Window and ask it what Forms!Hidden.TimerInterval is and it's 60000, so I know the form is open. I ask what the OnTimer event is and it's the correct macro.

Specifically which global settings are you referring to?

 

[TheAceMan1]

MacroScope . . .

Don't assume for us .... remember you came to us! ... at least do the little things we ask! ... we cant't see and we are not mind readers. If you do what I asked on 3 Jul 13 19:44 the result would be informatve.

See Ya! . . . . . .

Be sure to see faq219-2884 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]

 

[MacroScope]

AceMan, I understand you're not a mindreader and I sincerely appreciate your help, along with that of everyone else.

Here's what you asked 3 Jul 13 @ 19:44

Quick & dirty ... what happens if you overwrite the bad frontend db with a copy of a frontend that works? If this fails, we need to see the code in the OnTimer event.

I don't know how to answer the first part except to say that a bad copy doesn't exist that I know of. On each login a script runs which replaces the C:\ copy with a copy of the the same P:\ (public) drive file that everyone else gets. If you want to consider the file that's on this one particular computer's C:\ drive as a "bad" file, then the answer is that it is automatically overwritten with a "good" one at each login, and no matter how many times that is done it doesn't make a difference.

The action called by the OnTimer event isn't code, but a macro. It runs once a minute and consists of probably 8 steps, each evaluating whether a different condition exists and then responding accordingly to any found to be true. The conditions looked for and the individual actions taken in response only make sense in the larger context of what each step is designed to accomplish, and honestly, to save you unnecessary time you should understand that I've considered and tested for this by stopping all future actions from running and leaving only one step in the macro, a MsgBox. In other words, I replaced all the normal steps with one single step - a MsgBox with no conditions that gives me a visual indication of when it has triggered. It usually fires only once, even with only the single action tied to the OnTimer event.

What I do find intriguing is the fact that as far as I can remember it always fires at least once after AutoExec runs and the hidden form containing the OnTimer event opens.

I'm not trying to avoid your question, but I'm quite certain that I have eliminated the possibility that the normal steps might be responsible by completely removing them. A one-step macro with the MsgBox as the only action usually fires once (very occasionally twice) and then doesn't fire again. If you still think that it would be valuable to see the normal steps that I have eliminated for test purposes I would be happy to show them to you.

Given the simplicity of the action, a simple OnTimer event that runs a one-step (for test purposes) macro, coupled with the fact that this whole thing works flawlessly on 19 other machines, I'm inclined to think that PHV's suggestion that some difference in the settings of Access on this work station might be responsible, but I don't know what those might be.

 

[TheAceMan1]

MacroScope . . .

Understood! Have the OnTimer call a routine in code that has a msgbox and see what happens. This will certainly tell us if its macro related.

BTW ... you need to be sure you close each msgbox window in time to receive the next trigger. Reason being msgboxes are modal and rob the focus. As long as one is open the OnTimer wont trigger!

Your Thoughts?

See Ya! . . . . . .

Be sure to see faq219-2884 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]

 

[MacroScope]

Sure, I can do that. It will be interesting to see if anything changes.

And yes, of course I do close each MsgBox in anticipation of the next (which doesn't come)!

I'm not sure when I'll be able to get back to work on this, but I'll post any additional info.

Just out of curiosity, are there any Access settings that could cause this, where the particular local installation of Access on this station might somehow be at fault?

 

[missinglinq]

The point is that everyone's C:\ copy is identical...which in my mind eliminates local corruption as a possibility.

Not true...everyone's copy was copied from an identical copy, not the same thing. Files can and do become corrupted through the simple act of copying. Not sure why one machine would repeatedly have this problem.

By the way, I always run Compact and Repair before the copy/paste/rename operations

You should also be aware that running a C & R can, paradoxically, cause corruption. Just something to keep in mind.

The Missinglinq

Richmond, Virginia

The Devil's in the Details!

 

[MacroScope]

Honestly, missinglinq, I had never haerd of C&R causing corruption. How does one avoid that?

You're correct of course. Everyone's copy is copied from what might be referred to as the master copy on the P:\ (public) drive. It's not the same thing, but it is close. I suppose one test I could make (though frankly it seems more like desperate shotgunning than actual troubleshooting) would be to open the P:\ copy on the problem computer and see what happens there.

Are there any settings on the local copy of Access that might make it act differently than other local copies on other machines?

 

[lameid]

I can't think of any settings that would effect the execution of on timer on one machine versus another and I expect if anyone could think of one, they would list it.

But in any case, you could have the same user try signing on to another machine and conversely try logging another user on to the problem machine (using a new copy of the file).

Different user means different access defaults or the default defaults. The user on the problem machine tests the copy process as only something like a script mapping P:\ to another server or something similar would cause an issue (or a leftover manual drive mapping to an old server still locked in).

 

[MacroScope]

I like that suggestion a lot! I'll definitely look at that as a possibility.

I'm not working on the issue right now. The company is just sort of living with it until they have enough stuff for me to do to come back, so for right now I'm in a holding pattern until further notice.

I'll definitely let you all know what I find when I get back at it, though.

 

[TheAceMan1]

MacroScope . . .

Don't forget my post [blue]5 Jul 13 0:21[/blue] ...!

See Ya! . . . . . .

Be sure to see faq219-2884 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]

 

[MacroScope]

Nope, Ace, didn't forget. I've definitely closed the msg box.

 

[TheAceMan1]

MacroScope . . .

[blue]Have the OnTimer call a routine in code that has a msgbox and see what happens. [purple]This will certainly tell us if its macro related.[/purple][/blue]

See Ya! . . . . . .

Be sure to see faq219-2884 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]

 

[MacroScope]

I saw that and commented that I thought it was an excellent suggestion. I also explained that the company has decided to live with it for a while and so I won't be working on it again until they call me back.

I will most definitely replace the macro step with a code step to eliminate (or confirm) the involvement of macro steps in the problem.