MS Access DB verliest verbinding om de zoveel tijd

[Operations]

Ik heb hier verschillende workstations staan, allemaal verbonden met een domain controller (server 2016). De workstations gebruiken Windows 7 en sommige Windows 10 in combinatie met Access 2016.

Alle workstations hebben overdag een Microsoft Access database open staan, vanaf een netwerk share. Ze zijn allemaal wired aangesloten.

Nu is het probleem dat een van de workstations (Windows 10), om de zoveel tijd (varieert van 15 tot 90 minuten ongeveer) een melding geeft dat een Access database niet meer beschikbaar is omdat de netwerk verbinding verbroken zou zijn. Dan sluit de gebruiker access af en start de database opnieuw en dan werkt het weer even.

De netwerkverbinding is echter helemaal niet onderbroken, de gebruiker heeft ook een aantal programma's open staan vanaf dezelfde (en andere) shares en die ondervinden geen problemen.
Als ik dit google komt het best vaak voor, maar alle suggesties zijn niet de oplossing. Deze dingen heb ik al geprobeerd:

- Power saving NIC uit;
- Netwerkshare wordt aangemaakt via Group policy. Hierbij gebruik ik al "UPDATE" ipv "CREATE";
- Network share aanmaken met IP adres ipv DNS name;
- "autodisconnect" dword aan maken in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters (met als waarde ffffffff);
-"KeepConn" dword aan maken in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters (met als waarde 65000);
- Access database offline beschikbaar maken

En als laatste heb ik ook geprobeerd:
net config server /autodisconnect:-1
net config server /autodisconnect:65000

Ook dat helpt beide niet.

Iemand een suggestie?

[ThinClientQ]

Andere netwerkdriver? Ik heb zoiets soortgelijks ook ervaren. Windows 10 had een standaard netwerk-driver geïnstalleerd; prima, alles functioneert! Internet, documenten, et c. Alleen bij een intensieve database applicatie hadden we ook deze problemen. De Dell driver installeren was de oplossing.

[Operations]

ThinClientQ schreef op woensdag 28 maart 2018 @ 12:55:
Andere netwerkdriver? Ik heb zoiets soortgelijks ook ervaren. Windows 10 had een standaard netwerk-driver geïnstalleerd; prima, alles functioneert! Internet, documenten, et c. Alleen bij een intensieve database applicatie hadden we ook deze problemen. De Dell driver installeren was de oplossing.

Ik was vergeten te vermelden dat ik dit ook geprobeerd heb. Helaas zonder het gewenste resultaat.

[HKS-Skyline]

Is het systeem technisch 100% gelijk aan andere systemen die de problemen niet hebben?

[Operations]

HKS-Skyline schreef op woensdag 28 maart 2018 @ 14:59:
Is het systeem technisch 100% gelijk aan andere systemen die de problemen niet hebben?

Niet allemaal, zijn er 4 gelijk aan dit systeem. Maar als je dit probleem opzoekt op Google, dan krijg je meerdere scenario's waarbij tientallen pc's 100% gelijk zijn en er dan toch maar 1 of 2 dit probleem hebben.

[HKS-Skyline]

Dan is een driverprobleem onwaarschijnlijk (tenzij er iets corrupt is). Ik zou eerder denken aan software zoals een antivirus pakket oid. Of wellicht dat access gevoeliger is voor packetloss en de lengte of plaatsing van de netwerkkabel het probleem is. Het is misschien wat ver gezocht, maar wellicht dat je het systeem kan verplaatsen om te testen of hij ergens anders wel werkt. Ik heb situaties meegemaakt waar een oude onafgeschermde kabel de boosdoener was.

[ Voor 4% gewijzigd door HKS-Skyline op 28-03-2018 15:11 ]

[Operations]

HKS-Skyline schreef op woensdag 28 maart 2018 @ 15:11:
Dan is een driverprobleem onwaarschijnlijk (tenzij er iets corrupt is). Ik zou eerder denken aan software zoals een antivirus pakket oid. Of wellicht dat access gevoeliger is voor packetloss en de lengte of plaatsing van de netwerkkabel het probleem is. Het is misschien wat ver gezocht, maar wellicht dat je het systeem kan verplaatsen om te testen of hij ergens anders wel werkt. Ik heb situaties meegemaakt waar een oude onafgeschermde kabel de boosdoener was.

Ik denk zelf ook dat access gevoelig is voor packet loss. Maar aan de andere kant, dan blijft het bijzonder dat het echt maar 1 pc is en dat het ook de hele dag door is op die ene pc (ipv 1 of 2 keer ofzo)

Ik zal straks de kabel even vervangen voor de zekerheid, maar denk persoonlijk niet dat het iets gaat opleveren.

[Frogmen]

Als de kabel niet gesmeed is door elfjes dan krijg je dit. zou inderdaad even een netwerk kabel over een ander traject proberen. Of 2 PC verwisselen kijken of het probleem mee verhuisd.

[ThinClientQ]

Geen leuke situatie, maar wat ik zou doen: Installeer het systeem opnieuw op een aparte SSD op een dag dat de machine niet gebruikt hoeft te worden. Of plaats een ander systeem tijdelijk bij de medewerker.

Installeer z.s.m. Windows en de basics op de aparte SSD en probeer het dan opnieuw. Access database openen en uren maken.

Hierna de resultaten evalueren.

[Operations]

Frogmen schreef op woensdag 28 maart 2018 @ 15:13:
Als de kabel niet gesmeed is door elfjes dan krijg je dit. zou inderdaad even een netwerk kabel over een ander traject proberen. Of 2 PC verwisselen kijken of het probleem mee verhuisd.

Kabel van wandcontactdoos naar pc een uurtje of 2 geleden laten vervangen. En helaas zie ik nu net weer de foutmelding verschijnen. Laatste wat ik nog kan proberen is de kabel omruilen met een andere pc die er vlak bij staat.(Dus andere wcd aansluiting) En Intel NIC in PCI-E slot proberen.

[ Voor 5% gewijzigd door Operations op 28-03-2018 21:32 ]

[Operations]

Ik ben hier nog even mee verder gegaan. Het lijkt toch een Windows 10 probleem te zijn. Ik heb verschillende vm's gestart en de vm's met Windows 10 tonen dit zelfde probleem.

[nescafe]

Zet dan Process Monitor erbij aan (filter op MSACCESS.EXE en drop filtered events). Kijk goed naar de target path en result column op het moment dat het fout gaat. Gebruik de waarde in de result column om te googlen. Maak vergelijkbare traces op machines waarop het goed gaat. Vergelijk deze globaal al dan niet exclusief registry-bewerkingen.

[Petser01]

Is er al een oplossing voor dit probleem. Komt bij mij ook voor na omschakeling naar Windows 10.
Diver update en andere suggestie zoals hierboven beschreven uitgevoerd zonder resultaat.

[Brahiewahiewa]

Een MSAccess database geshared over het netwerk is al sinds jaar en dag onbetrouwbaar.
Met twee of drie users is het nog te doen maar zo gauw het er meer worden is het één en al ellende.
Sla de database op in SQL server en gebruik Access alleen voor het ontwikkelen van de front-end

[Ben(V)]

Helemaal eens mee @Brahiewahiewa
Ms Access heeft net als bijna alle Microsoft Office onderdelen problemen met data op een Share.
Het is nu eenmaal ontworpen voor gebruik op een lokale disk en heeft problemen met timing als het vanaf een share moet werken.

Als alternatief zou je zo'n database gewoon op een server kunnen laten draaien en met bijvoorbeeld RDP de gebruikers op die server te laten werken.

[Rolfie]

Worden de drive mappings toevallig gemaakt via GPO en staat drive mapping op update?

Dit kan de nodige problemen geven, pas deze dan even aan naar create en test je database nog eens.
GPO refresh tijd is.... iets van 90 minuten...

Alternatief, gebruik eens een UNC path, blijft de database dan wel werken.
Of maak een nieuwe handmatige drive mapping met een andere drive letter. Probeer hem dan nog eens.

MSAccess kan gewoon goed draaien vanaf een netwerkshare. Ik heb heel wat databases gehad, en zelden echte problemen gehad, inclusief WAN's.
Is het ideaal, nee, maar overal werkt het gewoon.

[Plopeye]

@Rolfie Dit is inderdaad een lelijke, als de optie op replace staat dan is wat er onderwater gebeurt bij deze policy refresh actie is dat deze de share even kort verwijderd en opnieuw aanmaakt. Dit is genoeg om access maar ook andere software onderuit te helpen. Update daarintegen zou goed moeten gaan.

Zie ook de volledige uitleg:
https://www.itpromentor.com/gp-crud/

[mash_man02]

Ik heb ook ooit zoets gezien bij een klant , bleek uiteindelijk door group policy's te komen die op vaste interval shares refreshen door ze te verwijderen en opnieuw aan te maken.

[Rolfie]

Plopeye schreef op donderdag 5 november 2020 @ 13:40:
@Rolfie Dit is inderdaad een lelijke, als de optie op replace staat dan is wat er onderwater gebeurt bij deze policy refresh actie is dat deze de share even kort verwijderd en opnieuw aanmaakt. Dit is genoeg om access maar ook andere software onderuit te helpen. Update daarintegen zou goed moeten gaan.

Zie ook de volledige uitleg:
https://www.itpromentor.com/gp-crud/

Ik dacht dat ik hem toen op update had staan, maar ik durf dit nu niet meer zo met zekerheid te zeggen.

Hij staat nu op create en werkt perfect.