Managemnt Informatie Systeem in MS Access, Query's laten MS Access crashen

[StudentDennis]

Beste mensen,

Ik ben bezig om management informatie op een overzichtelijke manier te rapporteren. Ik loop echter tegen het probleem aan dat veel van mijn query’s MS Access laten crashen (als ik op query uitvoeren klik). Een voorbeeld van een dergelijke query is:

SELECT Count([week 47 trips].duration) AS [Aantal ritten week 47], Count([week 48 trips].duration) AS [Aantal ritten week 48], Count([week 49 trips].duration) AS [Aantal ritten week 49], Count([week 50 trips].duration) AS [Aantal ritten week 50], FORMAT((Avg([week 47 trips.duration])/86400),"Short Time") AS [Gemiddelde reistijd week 47], FORMAT((Avg([week 48 trips.duration])/86400),"Short Time") AS [Gemiddelde reistijd week 48], FORMAT((Avg([week 49 trips.duration])/86400),"Short Time") AS [Gemiddelde reistijd week 49], FORMAT((Avg([week 50 trips.duration])/86400),"Short Time") AS [Gemiddelde reistijd week 50]
FROM [week 47 trips], [week 48 trips], [week 49 trips], [week 50trips];

Elke tabel bevat ongeveer 2500 rijen en 15 kollommen, maar ik heb het ook al bij kleine query’s op de zelfde tabellen. Is dit gewoon te veel data voor MS Access en moet ik aan professionelere oplossingen gaan denken? Of is er iets mis met mijn query’s of computer instellingen?

Gr Dennis

 

[OctaFish]

Dit riekt als een heel slecht genormaliseerde database. Al hoop ik dat [week 47 trips], [week 48 trips], [week 49 trips] etc ook al queries zijn die de gegevens uit één tabel halen. En in dat geval kun je al die queries vervangen door één query: een kruistabel. Eigenlijk twee: één voor de aantallen, en één voor het gemiddelde. Maar nu heb je vermoed ik een Cartesisch product gecreëerd, en die vreet geheugen.

 

[StudentDennis]

Beste Octafish, bedankt voor uw snelle reactie!

Er is geen normalisatie toegepast, omdat de procedure voor de gebruiker eenvoudig moet worden. Ik weet ook niet of dit wel nodig is. De data zelf is wel "schoon", er is een unieke sleutel, verder is het steeds dezelfde tabel die wekelijks bijgevoegd dient te worden. Er is geen afhankelijkheid van de data aan de andere tabellen, dus er zijn geen relaties gemaakt, omdat ik denk dat die niet nodig zijn, maar verbeter mij als ik het fout inzie.

Het is de bedoeling dat iemand gewoon van een website een export kan maken van een httprequest van navigatiesysteem informatie, dat kan omvormen naar een Excel bestand, en die weer importeren als tabel van die week in Access. (Dit proces wil ik later nog verder automatiseren met VBA bijvoorbeeld of een dataextractor, maar voorlopig wil ik een werkende procedure hebben).

Vervolgens wil ik historische rapportages maken doormiddel van formulieren. Dat lukt op zich wel. Hier werk ik met allemaal losse query's van bijvoorbeeld: aantal ritten in week 47, dan heb ik weer een query van alle aantal ritten van alle weken per week en vervolgens heb ik weer een query die ook andere zaken combineert en de gegevens uit al die andere query's haalt. Deze hoofdquery gebruik ik dan om een formulier (rapportage) van te maken.

Dit projectje is nog in de opstartfase, dus ik sta open voor ingrijpende veranderingen, en ben dankbaar voor uw hulp.

[week 47 trips], [week 48 trips], [week 49 trips] zijn de namen van de tabellen die ik importeer uit de Excel-bestanden. Duration is de kolom uit die tabellen die de reistijd in seconden bevat.

Verder is dit nog maar een deel van de informatie dit ik wil weergeven dus de query zal alleen maar groter worden.

Ik heb getest hoe het zou werken met kleinere tabellen. Dus 5 kollommen en 5 rijen per tabel. Dan worden de gegevens wel in 1 seconde weergegeven.

Ik heb normaliseren wel geleerd op school, maar snap niet hoe dat van toepassing is op tabellen die geen relatie met elkaar hebben.

Gr Dennis

 

[OctaFish]

Er is geen normalisatie toegepast, omdat de procedure voor de gebruiker eenvoudig moet worden.

Laten we eerst één ding duidelijk stellen: normaliseren heeft niets (lees: NIETS) te maken met 'eenvoudig in voor de gebruiker'. Eerder het tegendeel: in een niet-genormaliseerde database kun je foutieve gegegens invullen, in een genormaliseerde is dat (bijna) niet mogelijk. Je kunt in ieder geval de gegevensstroom vele malen beter inrichten. Als je (zoals ik vermoed) gegevens uit een ander pakket krijgt, dan kun je die het beste (gecontroleerd) in één tabel importeren die je dan kan gebruiken voor verdere analyses. Geen problemen meer...

 

[StudentDennis]

Bedankt voor de tijd en de tip om alles in 1 tabel te doen. Dat ga ik nu proberen

 

[OctaFish]

Als je de importtabel steeds dezelfde naam geeft, kun je het importeren redelijk automatiseren. Je kunt dan een toevoegquery maken waarin je een check inbouwt op dubbele import (wat je uiteraard niet wilt). De datatabel waarin je alles verzamelt kun je dan ook helemaal naar wens opmaken qua gegevenstypes. Zoals je vast al gemerkt hebt, maakt Access een zooitje van de velden bij een import. Door een vaste tabel te gebruiken heb je dus veel betere data tot je beschikking.