[Access] Rapport blijft hangen tijdens uitvoeren query

[Verwijderd]

Jongens (en meiden),

Ik zit met het volgende probleem.
Voor mijn werk heb ik in Access een Formulier gemaakt die de scores van de werknemers weergeeft. (Callcenter: scores per werknemer, per bestand en ook procentueel tov aantal telefoontjes). Dit wordt ter informatie op de werkvloer weergegeven. Achter dit formulier hangen een aantal queries die voornamelijk verschillende soorten records tellen in de tabel met de belgeschiedenis. Aangezien deze tabel gigantisch groot is duurt het uitvoeren van deze queries gezamelijk één of anderhalve minuut.
Het eigenlijke doel is om de scores realtime te kunnen laten zien. Dat is misschien wat teveel gevraagd dus laat ik nu via de Timer-methode van het formulier elke drie minuten het formulier verversen. Echter, dit duurt dan één á anderhalve minuut en tijdens die tijd is Access druk bezig en kan er niet gescrolld worden in het formulier (wat wel nodig is, want niet alles past in 1 oogopslag). Dat is dus erg vervelend want nu is zo'n 50% van de tijd het systeem niet echt werkbaar.

Ik zal het vast wel niet heel handig geprogrammeerd hebben, dat het nu zo lang duurt, maar dat is niet mijn eerste probleem. Ik vind het niet erg als er 50% van de tijd druk gerekend en geteld wordt, alleen ik zou graag het formulier in die tijd werkbaar houden. Bestaat er zoiets in Access als het verhogen van de prioriteit voor een operatie als 'scrollen' t.o.v. het uitvoeren van de query? Zo ja, hoe en waar stel ik dat in?
Zo nee, heeft iemand een ander idee voor een werkbare oplossing?

Alvast bedankt!

[looskuh]

In Visual Basic heb je daar het statement DoEvents voor, maar ik weet niet of dat ook in VBA zit, en of dat in jouw geval wel het gewenste resultaat oplevert. Het gevaar bestaat dan altijd dat er alweer nieuwe dingen uitgevoerd worden terwijl de vorige bewerking nog niet eens klaar was. En dan krijg je dus een foutmelding.

Ik zou eerst eens kijken of je niet op een slimmere manier je queries kan organiseren. Is het wel nodig dat ie elke keer die hele lijst doorloopt en alle queries uitvoert? Valt er niet een view te maken die beter bij je behoeften past?

[Bud_s]

Een statistiek file introduceren ?

Deze kan je zeer klein houden, en laten updaten in het formulier waar ze hun belgegevens in muteren.

PS: sowieso even kijken of je indexen afgestemd zijn op je queries

[ Voor 21% gewijzigd door Bud_s op 26-08-2004 16:50 ]

[Verwijderd]

Jammer dat zoiets niet bestaat.

Ik denk dat een statement als DoEvents niet veel oplevert aangezien het verder ook niet vanuit VBA aangestuurd wordt (alleen eenmalig de timer-opdracht die het formulier vraagt om een requery).

Dan een efficientie-vraagje. Op dit moment zijn er verschillende queries die selecteren op basis van de verschillende eigenschappen. Query 1 telt alles met eigenschap A, Query 2 telt alles met eigenschap B en Query 3 telt alles met eigenschap C. Uiteindelijk ben ik geinteresseerd in het sommetje A/(A+B+C), bijvoorbeeld.
Dat sommetje kost nauwelijks rekentijd, maar de queries duren in totaal best lang. De queries bekijken immers afzonderlijk steeds de gehele tabel. Zou het schelen als je 1 query laat selecteren op A OF B OF C (combinaties komen niet voor) en dan gegroepeerd telt per eigenschap?

Eventueel zou dat het al veel werkbaarder maken, of denk ik verkeerd en maakt dat niet uit?

Als dat nog niet opschiet moet ik denk ik toch maar naar een andere aanpak kijken die niet steeds de hele database bekijkt.

Edit:

PS: sowieso even kijken of je indexen afgestemd zijn op je queries

Wat bedoel je hiermee?

[ Voor 6% gewijzigd door Verwijderd op 26-08-2004 20:27 ]

[Bud_s]

Als ik het goed kan inschatten, gebruik je nu 3 queries, die misschien wel in een keer kan.
scheelt je een factor 3.

Post je queries eens, dan kunnen we wat meer zeggen, kan ik gelijk een advies geven over het creeeren van een index (die je waarschijnlijk nog niet hebt)

[Verwijderd]

Je spit dus telkens weer dezelfde gegevens door + de nieuwe data zeg maar? dat moet anders kunnen

waarom niet gewoon de waarden opslaan (bv: 1800 telefoontjes gepleegd in x minuten met x% score), en daar vervolgens de nieuwe waarden tov de oude run van het script bij optellen, de D staat even voor delta oftewel verandering: 1800+D telefoontjes in x+D minuten met x%(bereken opnieuw) score.

Zo analyseer je telkens alleen maar de nieuwe data. Voorwaarde is dat je wel de tijden van de telefoontjes kunt achterhalen (of weten wat het laatste telefoontje was als je bv met een autoincrement werkt). Als ik heel fout zit moet iemand het me vertellen, maar zo zou ik het doen

[Verwijderd]

Ik ben het inmiddels wat anders gaan doen. Heb niet meer verschillende queries om de data te lezen maar ik doe het met de volgende query:

code:

INSERT INTO Stats ( Finishcode, Bestand, Agent, Aantal )
SELECT H.FinishCode, H.CampaignId, H.Agent, Count(H.FinishCode)
FROM CallHistory AS H
WHERE (H.FinishCode="Bezwaar" OR 
      H.FinishCode="NOF" OR 
      H.FinishCode="Verwijder Klant" OR 
      H.FinishCode="Opgehangen") 
    AND 
      Format([H].[CallDate],"d-m-yy")="26-8-04"
GROUP BY H.FinishCode, H.CampaignId, H.Agent;

Ik vul dus nu steeds een stats tabel met een aantal interessante data. Daar laat ik verder nog wat bewerkingen op los totdat ik precies de gegevens heb die ik wil. Die bewerkingen zijn verder niet heel relevant.

Momenteel duurt deze query zo'n 35 seconden (al een hele verbetering t.o.v. de oorspronkelijke anderhalve minuut).

waarom niet gewoon de waarden opslaan (bv: 1800 telefoontjes gepleegd in x minuten met x% score), en daar vervolgens de nieuwe waarden tov de oude run van het script bij optellen

Dat zou ik graag zo doen, alleen het is niet zo eenvoudig om de nieuwe waarden te vinden t.o.v. de vorige run. Er bestaat wel zoiets als CallTime, maar dat is het tijdstip waarop de Call beëindigd is. De tijd waarop het weggeschreven wordt is soms later doordat er nog wat bewerkingen gedaan moeten worden (achterlaten notities bij het gesprek e.d.). De volgorde waarin ze weggeschreven worden is dus niet met een oplopende CallTime, dus dat kan ik niet gebruiken. Er bestaat niet zoiets als wegschrijf-tijd o.i.d.

Heeft iemand nog verbeteringen voor mijn query of andere ideeën die me kunnen helpen?

[_js_]

Format([H].[CallDate],"d-m-yy")="26-8-04"


Dat is langzaam, nu moet een datum veld omgezet worden in een string voor elke rij in de database, en werken indexen niet. Als H.CallDate alleen een datum is dan

code:

H.CallDate = #2004-06-26#

als het datum+tijd is dan

code:

(H.CallDate >= #2004-06-26# and H.CallDate < #2004-06-27#)

En H.FinishCode kan een getal zijn.


Een index kan op CallDate, FinishCode, CampaignId, Agent.

[Verwijderd]

Bedankt voor de tip over die datum, ik ga het vanavond meteen proberen.

En H.FinishCode kan een getal zijn.


Een index kan op CallDate, FinishCode, CampaignId, Agent.

Ik voel me dom met al mijn vragen, maar wat bedoel je met deze twee opmerkingen?