Access 2016. Vastlopen Access.

Status
Niet open voor verdere reacties.

KPTPTT

Gebruiker
Lid geworden
2 mrt 2018
Berichten
321
Hallo. Het komt veel voor dat Access 2016 vastloopt. Er moet dan opnieuw worden opgestart of de database BE worden gecomprimeerd/hersteld.
Access is gesplitst in een FE en Be. De BE en FE's zijn via een klein netwerk met elkaar verbonden (via een netwerkverbinding K-schijf). Er zijn 2 gebruikers en de grootte is momenteel ongeveer 2000 records. Zodra een formulier wordt geopend of geswitched wordt tussen twee formulieren, dan loopt deze vast. Windows cirkeltje blijft draaien en het scherm grijst uit. Opnieuw opstarten is de remedie. Ook is er regelmatig de "inconsistentie" waarschuwing.

Ik zit te denken om over te stappen naar SQL-server waarbij de FE Acces wordt hergebruikt echter, de BE converteren naar SQL kan alleen als Office Access een 64 bit versie is, Is dat zo? Onze versie Office Professional 2016 is standaard 32 bits dus converteren ???

- Wat zijn de ervaringen?
- Wat is het advies?
- Overstappen of de huidige database stabieler zien te krijgen, hoe?
- Is SQL ook mogelijk op basis van 32 bits?
- Hoe kom ik aan Office 64 bits?
- Zou de netwerkverbinding een oorzaak kunnen zijn? Ik heb gebruik gemaakt van een virtuele schijf K:\ . . . en ga nog wel testen met een koppeling op basis van het volledige netwerkpad (\\xxx\ . . .).
 
Access databases kunnen al vanaf het begin worden gemigreerd naar SQL Server (Express), dus daarvoor hoef je geen 64 bits versie te gebruiken. Beide versies staan overigens op de CD.
Het probleem zal veel eerder in je FE liggen dan in je BE, die, als het goed is, alleen de tabellen bevat. + eventueel wat onderhoudsqueries en formulieren. Je FE tegen de nieuwe db aanplakken zal dus vermoedelijk de problemen niet oplossen. Met een lekke band op een andere weg gaan rijden, helpt tenslotte ook niet :).

Beter kun je een nieuwe FE db maken, en daar alle objecten in importeren, kijken of dat helpt. Vaak zit er in dit soort gevallen iets corrupts in je db wat niet te achterhalen is. Een schone versie maken wil dan nog wel eens helpen.
Helpt dat niet, doe het dan nog een keer, maar importeer de objecten dan in brokken. Dus eerst de queries (zullen doorgaans geen probleem opleveren), dan een paar formulieren waarmee je een deel van de processen kunt uitvoeren, dan de volgende batch en zo verder. Geheid dat je dan het formulier kunt lokaliseren wat het probleem is. Dat moet jemdan opnieuw maken.
 
Dank voor je inzicht en het meedenken. Ik heb ook het gevoel dat het de FE is en daarom twijfelde voor de SQL oplossing en om raad vraag. De FE in de bedrijfssituatie op het netwerk loopt steeds vast. Op mijn laptop is dat nog nooit gebeurd en ook niet na te bootsen in een stresssituatie (ik ben een "beruchte" tester :confused:) . Zou daarom, vanwege de verschil in de bedrijfstoestand, netwerkissues een rol kunnen spelen?
De FE in stukken maken en testen kan niet in de bedrijfssituatie. Dus ik moet alles opnieuw maken en dan het geheel in de praktijk gaan testen, poef.

Als ik de FE opnieuw zou moeten maken dan begrijp ik dat het volgende mogelijk is:
- Queries 15 sts importeren of opnieuw maken. Hoe kun je queries importeren?
- Formulieren 13 sts opnieuw ontwerpen, kan er ook een kopie worden gemaakt? Twee formulieren zijn veel tekenwerk, conform een bekend bedrijfsformulier. Het houdt ook nieuwe buttons in. Wat te doen met de VBA code die naar de nieuwe buttons en keuzevelden moeten wijzen?
- Rapporten 17 sts opnieuw maken.
- VBA code kopiëren en plakken in de nieuwe FE.
Alle formulieren en rapporten worden dagelijks gebruikt en kan dus niet in gedeelten.

Wordt met kopiëren de fout niet mee gekopieerd? Heb je zoiets ook al eens gedaan? Wat zijn je bevindingen?
 
Je kunt alles importeren: tabellen, queries, formulieren, rapporten, modules... Kortom: in essentie hoef je niks opnieuw te maken. Hooguit zul je wellicht de bestaande code opnieuw moeten koppelen aan de knoppen en keuzelijsten; het kan zijn dat die niet automatisch gelegd worden bij importeren. Al maak ik dat eigenlijk nooit mee. In dat geval: stel dat je een knop hebt met de gebeurtenis <Bij klikken>, en de gebeurtenis is verdwenen. Dan klik je op de knop met de drie puntjes, en dan zit je gelijk in de bijbehorende procedure. De knop is dan weer gekoppeld.

Maar het probleem zit dus vaak in de formulieren, en je zou toch eens moeten kijken of je die niet in gedeeltes kunt importeren. Ik kan mij niet voorstellen dat er geen enkel formulier niet werkt als niet alle formulieren aanwezig zijn. Dat zou duiden op een stevige spaghetti constructie :).
 
Het importeren scheelt een hoop werk. Ik kan wel formulieren apart testen en operationeel maken maar alleen zo niet (als gedeeltelijk db) in de bedrijfssituatie gebruiken. Op mijn ontwikkel laptop gaat het eigenlijk nooit fout. Je hebt het over "vaak in de formulieren", dat wil veel zeggen over de stabiliteit van Access. Ik ga zaterdag nog wel in de FE-BE koppeling de netwerkkoppelingen aanpassen. Ik heb ook in de VBA code de Error afhandeling voor iedere sub strikter doorgevoerd, wie weet helpt het.

Ik bedenk mij dat ik voor een attentiesignalering op basis van een bewaking van een ToDo actie, een timer laat lopen van 900 msec. Deze "ratelt" (interrumpeert) wel door alle VBA code heen. Kan dat de "kwaal" zijn?

Je schrijft dat ook de formulieren (lay out) en rapporten kunnen worden geïmporteerd, maar bedoel je eigenlijk; gekopieerd van de oude FE naar de nieuwe FE db? Ik zie wel importeren van de tabellen.
Ik ga eens goed nadenken en kijken hoe ik het op jouw advies kan gaan uitvoeren.
 
Ik zei wel ‘vaak in de formulieren’, maar niet dat het vaak gebeurt :). Wat ik bedoel te zeggen is dat formulieren meestal de oorzaak zijn als het fout gaat. En daar zit dan vaak ook de meeste code in.
 
Mijn vermoeden is dat het een netwerk issue is.
Je zegt dat FE en BE via een klein netwerk verbonden zijn.
Waar staat het FE precies, lokaal bij de gebruiker/gebruikster?

Tardis
 
Dank. Het netwerk bestaat uit een centrale pc (BE) op de zaak en daarop aangesloten via een (professionele) switch twee andere pc's (FE). Afstand nodes 15 meter.
Ik ga nog een proef doen met de timer. Deze loopt om de 900 msec. Ik heb er al last van als ik code schrijf en moet deze dan onderbreken. Ik zie de klok ook lopen in de titelbalk (knipperen) van de VBA code.
 
Ik heb de FE opnieuw geïnstalleerd en is het vastlopen wel minder en voorlopig acceptabel maar nog niet helemaal weg. Ook heb ik bovenstaand advies van OctaFish uitgevoerd. Op zich gaat het importeren van tabellen, query's, formulier flitsend (Menu Externe gegevens, Nieuwe gegevensbron, Uit database, Access, bron-adres invullen en importeren maar). Zelfs de relaties en VBA code worden geïmporteerd. Omdat ik Outlook email gebruik, moest ik de Outlook 16.0 Object library nog installeren.
In feite "loopt" de database weer echter een paar rapporten kunnen niet worden geïmporteerd. Er treden foutmeldingen op (Er is al een module, project of objectbibliotheek met deze naam-De zoeksleutel is in geen enkele record gevonden- De database engine kan het object Status naar . . . Opdrachtgevers niet vinden). De modulen en objecten bestaan. Ik kan dan maar ook het betreffende object (een formulier) niet als een nieuw rapport opslaan, ook hier weer de foutmelding.

Inmiddels . . .Ik heb alles vanuit een fe en be in één database geïmporteerd en daarna gesplist. De paar onwillige objecten herhaaldelijk nogmaals als rapport opgeslagen en dat lukte uiteindelijk. Dus nu is de gehele database weer werkend. Petje af voor Access, wat kun je er veel mee. Kijken of de database met de nieuwe "motor" nu stabieler is geworden, spannend.
 
Laatst bewerkt:
Ervaring na bijna twee maanden.
De database is nu stabiel en loopt niet meer vast. De oplossing was dus een nieuwe database maken en alle tabellen, formulieren en Query's, etc. vanuit de oude database naar de nieuwe importeren. Fluitje van een cent.
Daarna de database gesplitst in een FE en BE (Iedereen aan te bevelen). Let op: Bij het importeren is een fout opgetreden waarbij een paar rapporten niet konden worden geïmporteerd. Uiteindelijk is dit gelukt doch wordt door Access automatisch een foutrapport aangemaakt. Bij het splitsen staat dit foutrapport in de lijst met te splitsen modules. Zet het vinkje uit bij dit rapport waardoor dit foutrapport niet wordt meegenomen in de splitsing. De vernieuwing heeft een hoop problemen weggenomen.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan