Access 2019 : disconnections (1 Viewer)

[Alain CHAZOT]

Hello everyone,

(sorry, this is a Google translation from French to English)

I developed an Access application which includes a main base of 35 MB and another base of 70 MB for the linked tables.

It runs on about fifteen PCs on a corporate Ethernet network.

Problem: Users complain of frequent disconnections. Access no longer finds linked tables and displays "?" or "#" in place of data with an error message indicating that the network has been lost or disconnected.

A network audit was carried out by a specialized company but it did not reveal anything abnormal.

After having read what is said on this subject on the net, I modified the addressing of the tables which were written with a network letter at the origin (T:\ in this case) to write it "in hard " with an address like \\servername\directory\file

That should have solved the problem.
But no, the problem persists.

Before installing this new database, we used other Access databases built on the same model and on the same network and we did not have these disconnection problems.

So I come to think that the problem is probably not attributable to the network itself but rather to Access.

What reinforces this hypothesis is also that only Access poses a problem. No worries with the other tools in the Office pack, or with others for that matter.


Have you ever had this type of problem?

Do you know where this problem can come from and how to fix it?

Thank you very much for your precious help.

Alain

 

[SHANEMAC51]

which includes a main database of 35 MB and another database of 70 MB for related tables.

It runs on about fifteen PCs on a corporate Ethernet network.

----
each of the 15 users has its own instance of the main database or all are part of the same database

 

[GPGeorge]

Hello everyone,

(sorry, this is a Google translation from French to English)

I developed an Access application which includes a main base of 35 MB and another base of 70 MB for the linked tables.

It runs on about fifteen PCs on a corporate Ethernet network.

Problem: Users complain of frequent disconnections. Access no longer finds linked tables and displays "?" or "#" in place of data with an error message indicating that the network has been lost or disconnected.

A network audit was carried out by a specialized company but it did not reveal anything abnormal.

After having read what is said on this subject on the net, I modified the addressing of the tables which were written with a network letter at the origin (T:\ in this case) to write it "in hard " with an address like \\servername\directory\file

That should have solved the problem.
But no, the problem persists.

Before installing this new database, we used other Access databases built on the same model and on the same network and we did not have these disconnection problems.

So I come to think that the problem is probably not attributable to the network itself but rather to Access.

What reinforces this hypothesis is also that only Access poses a problem. No worries with the other tools in the Office pack, or with others for that matter.


Have you ever had this type of problem?

Do you know where this problem can come from and how to fix it?

Thank you very much for your precious help.

Alain

This is more likely a network problem, sorry.

Tell us more about the network. Wire or WiFi?

Access is notoriously more "chatty" than other applications. A lot of traffic gets passed back and forth between the FE and the BE. Each time you open a form or report, query a combo box, etc., etc., your accdbs send messages back and forth and retrieves or sends data to do those things. That's what is meant by the term," chatty."

Opening a Word document, for example, simply doesn't result in that kind of activity. So, comparing Access to other Office applications is a rough estimation at best.

What you are looking for is probably one of two things. First, and perhaps less likely would be network drops (which may or may not show up in an audit if they weren't specifically looking for that). Second, and what sound more likely given the information provided, is a time out on connections between the two accdbs.

Addressing the first could be as simple as making sure no one connects via WiFi. However, such problems are notoriously hard to pin down.

Addressing the second could potentially be resolved by implementing a persistent connection. Although persistent connections are more frequently associated with slowness, if preventing timeouts is also a result, that could be helpful as well.

 

[Pat Hartman]

Sometimes this is caused by ONE bad NIC card somewhere on the network. So an app that worked for years, now starts dropping.
Also if you are using WiFi rather than hard wired connections, you will be much more prone to drops.

 

[Alain CHAZOT]

Hi all,

thanks a lot for your answers.

For your information, as said in the post, we use an Ethernet network, so an wire network. We don't use Wifi with Access.

Alain

 

[mike60smart]

Hi Alain
Can you confirm that the database is split into FE and BE and that all users have a copy of the FE on their C: Drive?

 

[Pat Hartman]

I mentioned WiFi because I had a client with both in the office and people were sloppy about how they connected to the network so if you have the option, make it clear to people that they need to use the wired connection

Regarding the NIC cards, I think unless they are acting up at the moment, standard scans don't identify them. You have to test them specifically.

 

[GPGeorge]

I mentioned WiFi because I had a client with both in the office and people were sloppy about how they connected to the network so if you have the option, make it clear to people that they need to use the wired connection

Regarding the NIC cards, I think unless they are acting up at the moment, standard scans don't identify them. You have to test them specifically.

As an example of "intermittent" network problems, the very last client I worked for had a rather random approach to network cabling. One of their computers was serviced by a cable that actually ran over the top of a fluorescent light fixture, rather than through the ceiling where it should have been. When the ballast came on, it briefly interrupted the flow in that cable. And at random times it apparently did the same thing. If the fluorescent flickered, the network blipped too. The fix turned out to be moving the cable a few feet....

 

[Alain CHAZOT]

Hi,

for mike60smart : yes Mike, I confirm. Data are on a drive of the network and a copy of forms and queries on c:

Alain

 

[Alain CHAZOT]

Thanks a lot GP George and Pat !