Hoe komt het nu dat mijn Microsoft Access database corrupt is?

Een paar overwegingen als een Access database wordt gebruikt in een VB6 applicatie.

In veel gevallen is data corruptie in een Access database niet direct het gevolg van slecht programmeren.
Vaak zijn het externe factoren die ervoor verantwoordelijk zijn dat een Access database corrupt raakt.

In tegenstelling tot 'managed' SQL Server, MySql, Oracle en meer van dat soort databases is Access eigenlijk een beetje een buitenbeentje.
Access is feitelijk nog steeds een bestand georienteerde database.
Hoewel meerdere gebruikers tegelijkertijd van de database gebruik kunnen maken is het lezen maar vooral het schrijven nog steeds gebruikers geinitieerd. Van meerdere kanten kan ongecontroleerd in de database worden geschreven.

Probleem is nu dat als de verbinding tussen de applicatie en de database om een of andere reden verbroken wordt dat de database dan mogelijk achterblijft in een onvoorspelbare staat. 
Meestal gaat het wel goed omdat alle schrijfacties vlak na elkaar plaatsvinden en de database dus snel weer een consistente staat aanneemt.
Als de verbinding echter midden in een update verbroken wordt dan is het niet te voorspellen wat de staat van de database is. 

Als er dus geen maatregelen worden genomen om corruptie te voorkomen dan gaat het van tijd tot tijd dus een keertje FOUT.
Soms is de database dan gewoon 'corrupt'. Kapot. Kaduuk. Onherstelbaar.

Zonde......... Want met wat eenvoudige ingrepen is dit allemaal te voorkomen.

Laten we even kijken naar de vormen van corruptie die voorkomen kan worden.

Fouten bij het ontwerpen van een database.
Bij het ontwerpen van een database wordt vaak volstaan met het snel definieren van wat tabellen.

Dat is nu jammer. 
Met een beetje ontwerp worden heel veel problemen bij het programmeren voorkomen.

Neem een eenvoudige structuur van 'Orders' en 'Orderregels'. Dit is een een op veel relatie.

Er zijn twee mogelijkheden om deze structuur in stand te houden.

Consistentie wordt in de VB6 applicatie zelf geregeld.
Dat kost een hoop programmeer inspanning en het levert soms toch een situatie op dat er 'orderregels' zijn zonder de bijbehorende 'order'. 
Consistentie wordt in de Access database geregeld.
Dit is de juiste oplossing omdat Access nu per definitie voorkomt dat de bovenstaande fout kan optreden.
Nadeel is wel dat Access nu meer fouten naar de VB6 applicatie kan teruggeven. Deze foutmeldingen moet het VB6 programma wel gaan afhandelen.
Als programmeur moet je natuurlijk wel even de tijd nemen om een goede foutafhandeling te programmeren.
Ook moet goed worden nagedacht over de relaties in de database en deze moeten dan ook in Access worden ingevoerd.

Niet gestructureerd programmeren wordt nu gelijk afgestraft. 
Je zult je nu in je VB6 applicatie moeten houden aan de door jou zelf bepaalde structuur in de database.
'Knutselen' is taboe. Helemaal niet erg. Dat maakt het verschil tussen de amateur en de professional.
 
In de database worden wijzigingen weggeschreven. En dat proces stopt op een niet gepland moment. 
Dit gebeurt bijvoorbeeld als de computer zomaar wordt uitgezet.
Op dat moment kan het gebeuren dat bepaalde informatie wel en bepaalde informatie nog niet in de database is geschreven.
In dit geval is de database fysiek corrupt. Databasepointers en definities verwijzen niet meer juist naar elkaar.

Dit soort corruptie is moeilijk te repareren.
Het microsoft tool van 'compact en repair' werkt nu vaak niet meer.
Soms moet de database als echt verloren worden beschouwd.
Zonde.......

De oplossing is het gebruik van 'transaction-control'.
Wordt transaction-control toegepast dan zorgt Access er zelf voor dat bij het schrijven in de database zogenaamde 'before-' en 'after' images worden aangemaakt. Als de verbinding met de database nu plotseling wordt verbroken dan is de database op dat moment wel fysiek corrupt. Dit is echter niet erg omdat Access nu bij het openen van de database kan vaststellen dat de transactie niet is voltooid. 
Access draait vervolgens zelf de transactie eenvoudig terug. 
Voila: De database is geheel automatisch hersteld. 

Natuurlijk is de laatste transactie niet uitgevoerd. Dat weet je. En dat is goed af te vangen in een VB6 applicatie.

Samenvattend:

Gebruik 'Transaction control'.
Gebruik vaste relaties in de database. Dwing de 'referentiele integriteit' gewoon af.
Gebruik een beperkt aantal kolommen in een tabel. Hoe meer kolommen hoe sneller een database corrupt raakt.
 

Sprookjes:

Een Access database is niet geschikt als het een grote database betreft
Een Access database is een geschikte database tot ongeveer 1 gigabyte.
Een Access database is niet geschikt als er meerdere gebruikers (veel gebruikers) van de database gebruik maken
Nooit problemen mee als de bovenstaande punten in de samenvatting onverkort worden nageleefd.