Zoeken laatst beschikbare data

Status
Niet open voor verdere reacties.
Queries met subqueries blijven continue herberekenen, en dat is niet goed voor de snelheid. In dat geval zou ik een tijdelijke tabel maken op basis van de selectiequery en die tijdelijke tabel gebruiken in de toevoegquery.
 
Hi Octafish,
Zit er een tijdje naar te kijken, maar wat bedoel je precies met een tijdelijke tabel, datgene wat je in hoofdstuk 10 van jouw tutorial hebt behandeld...?
Gr
 
In mijn voorbeeldje gebruik ik alleen de queries, want ik doe verder weinig met de data. Een toevoegquery werkt dan blijkbaar net iets anders, en daarom het idee om eerst een aparte tabel te maken en die te vullen met de selectiequery en de toevoegquery dus te maken met die tijdelijke tabel. Dan heb je er weer vaste data in staan i.p.v. dynamische. Dus ofwel de selectiequery ombouwen naar een Tabelmaak query, of een tabelmaakquery maken en daarvoor de selectiequery gebruiken.
 
Hi Octafish,
Bedankt voor het advies, ik heb nog eens zitten trial and erroren en ik snap waarom hij zo lang bezig is.
Dit komt omdat bij heel veel producten er elke maand gewoon al een prijs beschikbaar is, die dan niet wijzigt bijv.
Datum: Prijs:
1-1-2013 €8,-
1-2-2013 €8,-
1-3-2013 €8,-
1-4-2013 €8,-
1-5-2013 Geen prijs
1-6-2013 Geen prijs
1-7-2013 Geen prijs
1-8-2013 €7,-

Nu geneneerd hij het volgende:

StartDate: Enddate Prijs:
1-1-2013 31-1-2013 €8,-
1-2-2013 28-2-2013 €8,-
1-3-2013 31-3-2013 €8,-
1-4-2013 31-7-2013 €8,-
1-8-2013 18-3-2015 €7,-

Dit is dus eigenlijk onnodige data, dus misschien is het slim om eerst dit te generen uit de raw data:

1-1-2013 31-7-2013 €8,-
1-5-2013 18-3-2015 €7,-

Dit zal veel data schelen waardoor de database/query waarschijnlijk sneller gaat lopen :D?
Enig idee hoe je dit aanpakt?

Gr
 
Ik had dat inderdaad ook gezien in je tabellen, en mij al verbaasd over het waarom :). Zelf hanteer ik een constructie waarin de mutaties worden bijgewerkt als dat nodig is. Dus in de tabel zou je al die overbodige records gewoon weg moeten kunnen gooien. De zoekfunctie vindt de goede prijs toch wel op basis van de range. Of die range nu loopt van 1-1-2014 t/m 31-1-2014 of van 1-1-2014 t/m 31-4-2014 maakt echt niet uit; een prijs op 13-3-2014 is hoe dan ook te vinden. Het voordeel hiervan is ook dat je bij de meest recente prijswijziging geen einddatum hoeft in te vullen; de prijs loopt immers door t/m vandaag en dat kun je prima in de functie vangen met Date() als einddatum te gebruiken bij het laatste record.
Dus een query kan, maar beter nog is je tabel aanpassen.
 
Maar hoe pas ik dan die tabel aan, dmv een query?
Die prijzen die haalt hij uit een hoofddatabase waarbij access de waarde van de verkochten goederen deelt door de qty.... Daar komt dan vervolgens die raw data uit met prijzen per maand periode. Als een product dus niet verkocht is, mist er een prijs, hoe ziet die constructie er dan uit waarin de mutaties alleen worden bijgewerkt indien nodig?
 
Laatst bewerkt:
Als een product dus niet verkocht is, mist er een prijs.
Des te meer reden om de prijzen alleen te muteren (=toevoegen nieuw record en invullen einddatum vorige record) als er wijzigingen zijn. Ik zou dan een eigen prijstabel maken/gebruiken waar je de import dan op matcht. Die match doe je dan op basis van laatste record in de prijzentabel. Als de prijs van het artikel identiek is aan het laatste record, is er niks veranderd en hoef je dus geen record toe te voegen. Is er wel een wijziging, dan moet er dus een einddatum komen en een nieuw record. Ik zou dat automatiseren met een functie, want je hebt 2 acties: een bijwerkquery en een toevoegquery. Dat kan nooit in één handeling worden opgelost.
 
Klinkt erg eenvoudig octafish :p, heb je hier ook ergens een handleiding/tutorial voor haha
 
27 lessen Access in de Handleidingen sectie :). Maar dit soort handelingen is niet in een vast script te gieten, omdat er nogal specifieke handelingen bij nodig zijn. Dus een beetje 'common sense' is onontbeerlijk. Je kunt beginnen met de query te maken die de laatste prijsmutatie opzoekt (heel simpel: filteren op Einddatum Is Null) en daar maak je dan met VBA een Recordset van. Ook simpel: de SQL kopiëren en in een string plakken. Vervolgens maak je op dezelfde manier een recordset van de import tabel. En die twee recordsets kun je dan met elkaar gaan vergelijken, bijvoorbeeld door vanuit de import een lus te maken die de prijs vergelijkt met het overeenkomende artikelID.
De hele functie werkt dus met recordsets.
 
Oke Octafish, bedankt voor je hulp!
Ik ga over op excel, heb hiermee een oplossing die sneller werkt.
Thx voor de support! Gr
 
Ik ga over op excel, heb hiermee een oplossing die sneller werkt.
Dat bestaat niet..... Hooguit een oplossing die je sneller gemaakt hebt ;). Bestuur ik hier een stukje vluchtgedrag? :D
 
Hi Octafish,
Weet niet of het vluchtgedrag is, misschien een beetje.
Maar het is zo dat mijn oplossing nu 5min in beslag neemt en overzichtelijk blijft voor mij en eventueel toekomstige gebruikers.
Als ik het helemaal geautomatiseerd met access wil fixen ben ik denk ik nog wel 12uur minimaal zoet. Terwijl die 5min eens in de maand uitgevoerd dient te worden.
Doe de rekensom, dat betekend dat ik mijn manuele handeling in die 12 uur 144x kan uitvoeren. Dus is dat voor mij een oplossing die sneller werkt.
Gr. nogmaals bedankt voor de hulp, waardeer ik en ook voor de challenge haha!
 
Ik snap je rekensom eerlijk gezegd niet helemaal; als alles goed werkt in Acces is het een kwestie van één druk op een knop. Dat kost mij geen 5 minuten, laat staan 12 uur :). De rekensom zou dus moeten zijn: in Access - 30 seconden, in Excel - 5 minuten. Do the maths :D.
 
Ik bedoel dat het uitzoeken me nog 12uur gaat kosten....
Die tijd kan ik ook gewoon gebruiken 12*60)/5=144> 144/12=12jaar lang elke maand dat ding te update
Binnen die tijd is er wel een nieuw systeem dat fatsoenlijk werkt.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan