DJRino:
Hopefully I explained it better.
It was never about failing to understand your situation DJ. Possibly the reverse from what I see. I'm trying to make it clear what
you need to do (with my help where I can) in order to discover what your problem is.
I understand the logic of what you're trying to do. And, it should be added, are succeeding in doing under some circumstances. This doesn't take us forward at all though. I tried to explain a bit in my other posts but it seems we're a little at cross-purposes here. Rather than worrying about the logic of your code - which from what we know so far is probably quite adequate - we need to look elsewhere and try to discover exactly what is different where in the environments that don't work as expected.
For this we need to look at running some
exclusion tests. If you are still interested (I know this won't be simple work, and it's more involved due to explaining by the written word rather than using more immediately interactive methods, so you may choose not to get involved).
When testing out concepts it's important to simplify as much as humanly possible. EG. Does code run at all in the environment being tested? Create a separate database just for testing and get it to run as simple a bit of code as possible. Testing code you know runs elsewhere is simply not good enough. There are 1,000,001 different reasons why that particular code
may have problems in the environment. So, to avoid even having to think about whether or not a test is worthwhile with existing code, we
always strip to the very basics.
- Private Sub Form_Open(Cancel As Integer)
-
Call MsgBox("Test")
-
End Sub
For a Timer event you may want something that changes between firing so you can see it's ongoing. For instance have a Label control on the Form with code of the form :
- Private Sub Form_Timer()
-
Static lngX As Long
-
-
lngX = lngX + 1
-
Me.lblX.Caption = lngX
-
End Sub
Only when you know what is causing the issue can you consider the best way to correct it. As I said before - ensure the Timer is working by design and not reliant on code to trigger it.
Now, please refer back to earlier posts for required information. I still have nothing from you relating to AV software. It would also be helpful to know how a workstation that gets upgraded to full Access (rather than RunTime), without any other changes, behaves. It should be ok to return it to RunTime once we no longer need info from it.
I will certainly understand if you choose not to take this route, but I see no other way to garner the info you require. Certainly this situation is not one I've dealt with before.