Does network latency interfere with code execution?

[Avoraightu]

I have noticed lately that I am getting differences in the way the vba code is behaving when run from various network computers.

For example, a couple of weeks ago I introduced a new data entry form for our production group. The form and code worked as expected when I tested it at my workstation, but when I tried the same application on our boardroom computer several of the form events failed to fire on numerous attempts.

Today when they tried to use the application on the production floor once again the form events failed to trigger.

Could this be due to network latency? could it be the version of Office 365 that is installed? or something else that I need to change.

We are running a split front end with SQL and I am developing with the 64 bit version of Access with Office 365.

Thanks in advance.

 

[theDBguy]

You're saying the events "fail to fire," how did you confirm that? I can't imagine network latency would have anything to do whether an event would fire or not. It might have an effect on the code being executed, such as if you're fetching a large amount of data from the server.

 

[Avoraightu]

The event triggers a Yes/No message box, and the code executes based on the user selection.
During my demonstration there was no popup message, and I was told there wasn't one on the production floor.

I still have to go down and confirm it, and i know that the wireless connection is a bit flaky so I'm just trying to reduce the potential causes.

thanks for the reply.

 

[theDBguy]

Were they using the db from a Trusted Location?

 

[Avoraightu]

I should have time tomorrow to dig a bit deeper, they have been using that workstation before but that does bring up a good point.
We typically upload the file to sharepoint and have them download it locally, I should check to see where they are running it from.

 

[isladogs]

Access should never be used with a wireless connection. If the WiFi gets interrupted whist data is being written, corruption is highly likely.
Whilst SQL Server is more resilient than Access. this is a potential disaster waiting to happen.
Code not executing may be the least of your problems,

 

[Isaac]

I should have time tomorrow to dig a bit deeper, they have been using that workstation before but that does bring up a good point.
We typically upload the file to sharepoint and have them download it locally, I should check to see where they are running it from.

Can you describe what event it was, what code was in the event, and what type of scenario you believe 'should' have fired the event+code ?

 

[CJ_London]

also, can you confirm the app is split backend and front end and each computer is using its own copy of the front end i.e. one located on their local drive.

 

[Avoraightu]

It's nothing very complicated.

The user makes a selection from a combo box, if for some reason they don't select anything then the code is not supposed to execute.
Otherwise a message box is supposed to popup offering a Yes / No selection.

Like I said it works fine on my desktop but I am struggling to understand why it wouldn't work the same on any

Access should never be used with a wireless connection. If the WiFi gets interrupted whist data is being written, corruption is highly likely.
Whilst SQL Server is more resilient than Access. this is a potential disaster waiting to happen.
Code not executing may be the least of your problems,

Ya that's something I don't have much control over, I have voiced my concern and they say they are going to upgrade the access point.

 

[Avoraightu]

also, can you confirm the app is split backend and front end and each computer is using its own copy of the front end i.e. one located on their local drive.

It is definitely split, however I am relying on them to download and install locally, I need to check that for sure.

 

[Isaac]

It's nothing very complicated.

The user makes a selection from a combo box, if for some reason they don't select anything then the code is not supposed to execute.
Otherwise a message box is supposed to popup offering a Yes / No selection.

Like I said it works fine on my desktop but I am struggling to understand why it wouldn't work the same on any


Ya that's something I don't have much control over, I have voiced my concern and they say they are going to upgrade the access point.

You forgot to answer the part of the question about what event this is in.

If you don't provide specifics, then we're just guessing at our answers.

 

[Avoraightu]

Can you describe what event it was, what code was in the event, and what type of scenario you believe 'should' have fired the event+code ?

It is a very simple piece of code, the user makes a selection from a combo box, as long as something is selected a message box comes up with a Yes / No option for the user.

You forgot to answer the part of the question about what event this is in.

If you don't provide specifics, then we're just guessing at our answers.

It is on the "after update" of the combo box.

 

[Isaac]

It could be they didn't actually change the value of what was in the drop down

 

[CJ_London]

I am relying on them to download and install locally

don't rely on users to do what you expect - enforce it. Plenty of examples on this and other forums about how to do this. Look under the search criteria of something like 'access vba update user front ends' or similar

 

[The_Doc_Man]

FIrst, the direct answer to your question: ALL user-written VBA code is SYNCHRONOUS. That means nothing is happening in parallel within Access.

At most, there is some support for the idea that the ACE engine is capable of doing multi-threaded cleanup operations after a query is done, but even the ACE engine is SYNCHRONOUS when dealing with an Access front end. This is NOT true for back-end files managed by an active SQL engine such as SQL Server or ORACLE or one of the other "big boys" of DB engines. Such non-Access engines CAN be multi-threaded. It is also not true for disk I/O because the WINDOWS operating system can do what is called a "write-behind" - i.e. start writing a buffer and then letting your program proceed once the I/O is under way. But that kind of ASYNCHRONOUS behavior doesn't apply for inputs of the kind that would trigger any form-related event.

If there is a network delay, being SYNCHRONOUS means you must wait for it. Which means that nothing will fire without a signal. BUT if your users reporting this problem DO report that some actions work, then this is not a network problem. If it were, that would imply that the NETWORK is aware of what the app is doing and is selectively blocking/ignoring actions. That just doesn't happen.

Access is written in a way that it becomes extremely difficult to make it multi-threaded. Because of that difficulty of activating secondary threads (and considering your claim of simplistic code) I would say it is virtually certain that there is nothing going on with events due to network latency.

I believe that if an event didn't fire, its conditions weren't properly met OR if it has "safety" code to prevent certain actions under some conditions, that the safety code kicked in and made the event a non-event. This will not be a networking problem - unless you are running over WiFi, in which case a network drop could attack EITHER the Access output channel (the screen) OR the input channel (mouse & keyboard).

 

[Avoraightu]

I finally managed to get my hands on the laptop this morning, I was able to verify that the application was behaving differently.

As previously pointed out the network although causing a delay, wasn't interfering with the form event.
I don't know the exact cause of the problem, but I was able to overcome it by upgrading the MS Office software and ensuring that the application was in a trusted location and that the vba/macros were not being blocked in the application.

Thanks for all the help.

 

[theDBguy]

I finally managed to get my hands on the laptop this morning, I was able to verify that the application was behaving differently.

As previously pointed out the network although causing a delay, wasn't interfering with the form event.
I don't know the exact cause of the problem, but I was able to overcome it by upgrading the MS Office software and ensuring that the application was in a trusted location and that the vba/macros were not being blocked in the application.

Thanks for all the help.

Congratulations! Glad to hear you got it sorted out. Good luck with your project.

 

[The_Doc_Man]

Dollars to donuts that the "trusted location" was the biggest part of that problem. Glad you found it.