In query datumveld berekenen, obv datum van vorig record

Status
Niet open voor verdere reacties.
H

hoingkatleen

Gebruiker
Lid geworden
1 sep 2014
Berichten
87
Hoi,

Mijn hersens slaan in de knoop. ik heb volgende gegevens:
tabel3.jpg

Ik wil nu in een query die einddatum telkens berekenen. Voor spoed- en observatie is het ALTIJD opnamedatum + periode.
Voor verlenging (er kunnen meerdere verlengingen zijn), is het ALTIJD de laatst berekende einddatum+periode. En voor nazorg blijft het dezelfde einddatum als de laatst berekende einddatum.

Maar hoe formuleer ik fatsoenlijk 'de laatst berekende einddatum'? Die zit in principe in het laatste record met zelfde procedureID.

Alvast dank aan wie mijn hersens uit de knoop haalt :-).

Groetjes,
Katleen
 
Laatst bewerkt:
in SQL kan dat eventueel wel met een "CASE" (afhankelijk van de situatie), maar of dat het onderhoud van je frontend ten goede komt is maar de vraag.

Als je tabellen structuur het toelaat zou je dit direct met een JOIN mee kunnen nemen, maar dat is dus specifiek hoe je database eruit ziet. (een outer join met je huidige procedureID zou de laatste datum OF een "NULL" moeten geven in het gevraagde datum veld).

Persoonlijk zou ik er grotendeels omheen programmeren, maar dat is omdat ik geen acces kenner ben en meer algemeen database gebruiker.
 
Wat ook kan is dat ik niet de laatste einddatum neem, maar wel de meest recente uit de range vonnissen met zelfde procedureID.
Dat komt op hetzelfde neer, maar dan nog weet ik niet hoe dit te formuleren...
 
Je doet gewoon een outer join (zoals ik boven al aangaf) je krijgt dan in het join veld de datum of "NULL". Vervolgens moet je er wel voor zorgen dat er ergens "logica" (programmeren dus) is die in het geval van een "NULL" een andere berekening doet dan in het geval van een valide datum.

Maar misschien hebben de residente acces kenners een betere / nettere oplossing.
 
Outer Join? Gewoon een veld maken met een subquery die het laatste record ophaalt. Of de functie DMax gebruiken om het laatste record op te halen. Is allemaal niet zo moeilijk :). Ik zou zeggen: doe er een voorbeeldje bij zodat we wat voorbeeldjes kunnen maken.
 
Bekijk bijlage forum_subquery.zip

OK, hier dus een voorbeeldje. Ik zou dus een query willen waarin ik de velden vonnis, datum vonnis, periode in dagen, periode in maanden en dan de berekende einddatum krijg.
Die berekende einddatum is ingewikkeld:
Ik dacht een oplossing te hebben, nl. voor 1 procedure 'DatumBeginInvul' +Som periodes in dagen + Som periodes in maanden.
Alleen mogen de 10 dagen van de spoedprocedure dan niet meegeteld worden als er een observatie op volgt want dan tellen die 10 dagen dubbel.

OctaFish, kan jij me op weg helpen ajb?
 
Nou, dat laatste probleem denk ik te kunnen oplossen door in de query "spoedprocedure" er gewoon uit te filteren in het criterium :-).
Sorry dat ik het zo in stukken en brokken toevoeg, ik heb last van (traag) voortschrijdend inzicht :-D
 
Die snelheid is wel verklaarbaar; honing is nu eenmaal geen substantie waarvan de viscositeit als erg jofel (lees: laag) bekend staat :). (ik blijf je naam als honingkatleen lezen ;) )
Nou mis ik in jouw voorbeeldje volgens mij een veld dat verwijst naar de [ParentID] van een vonnis/procedure. Of zit ik verkeerd te kijken? Normaal gesproken sla je in een record dat volgt op een ander record dat recordID op zodat je het trapje simpel kunt maken. Om het wat makkelijker uit te leggen: als je een stamboom maakt begin je met een persoon vast te leggen. Die krijgt een PersoonID (eerste generatie). Als die persoon een kind krijgt, maak je een nieuw record aan voor dat kind, en vul je bij ParentID het PersoonID van de eerste persoon in (tweede generatie). (ja, in mijn wereld kan een persoon in zijn/haar uppie kinderen krijgen ;). Krijgt dat kind dan weer een kind, dan vul je bij dat (feitelijke klein)kind (derde generatie) het PersoonsID van het eerste kind ((tweede generatie) in. Op die manier weet je dus altijd wat het voorgaande niveau is. En dat mis ik dus in jouw tabel. Tenzij ik verkeerd kijk :).
 
Laatst bewerkt:
Dus in vonnis 2 maak ik een veld dat verwijst naar vonnis 1 binnen dezelfde procedure. Bedoel je dat?
 
Laatst bewerkt:
Dat zou een oplossing kunnen zijn. Hoeft overigens niet de ideale oplossing te zijn natuurlijk :).
 
Ik vind het ook niet ideaal, maar als het niet anders kan wil ik het wel proberen. Maar hoe weet het record van vonnis 2 dan welk zijn parentID is? Dat hoef ik dan toch niet handmatig in te vullen hoop ik?
Iets in je antwoord doet me vermoeden dat er een meer ideale oplossing is ;-). Daar ben ik nieuwsgierig naar.
 
Het alternatief is dat je met een extra veld de laatste beschikbare datum ophaalt, en met een IIF controleert op basis van status (vonnis dus in dit geval) of je de einddatum berekent op Opnamedatum of VorigeEinddatum. Zoiets :).
 
Ik weet eerlijk gezegd niet precies wat de beste aanpak is; ik vind de structuur namelijk niet echt geweldig. Zo heb je een keuzelijst gemaakt ("Vonnis") met de waarden
Code: 
"spoedprocedure";"observatie";"verlenging1";"verlenging2";"verlenging3";"verlenging4";"verlenging5";"verlenging6";"verlenging7";"verlenging8";"verlenging9"
En die is nou niet bepaald genormaliseerd te noemen :). Normaal gesproken zou die er zo uit moeten zien:
Code: 
"spoedprocedure";"observatie";"verlenging"
Maar dat zou het dan weer noodzakelijk maken om met andere tabellen te gaan werken (één-op-veel koppeling met [Tbl_vonnissen]) of, zoals ik voorstelde, met een terugkoppeling naar het vorige record. Sowieso is een genormaliseerde oplossing beter, omdat je jezelf (of de baas) nu vastbindt op 9 verlengingen. Verandert dat aantal, dan moet je dat dus in de database structuur veranderen, en eigenlijk zou dat niet nodig hoeven te zijn. D.w.z. Je zult wel ergens moeten controleren op het maximale aantal verlengingen, maar dat moet een procedure aanpak zijn en niet een veldtechnische beperking.
Een ander probleem dat ik zie: bij Procedure 1 in je voorbeeld heb je 3 records, met dus 3 datums. Geen van de 2 vervolgdatums sluiten aan bij de vorige. Het observatierecord van 9-1-2007 heeft een periode van 40 dagen, dus je verwacht dan een verlenging in de buurt van 18-2-2007, terwijl jouw verlenging is vastgelegd op 30-1-2007. Daar zitten dus bijna 20 dagen tussen. Da's lastig rekenen :).
 
dat van die normalisering volg ik. Ik denk nog na wat het handigste is om dat op te lossen.

Maar die datums waar jij het over hebt, zijn de datums waarop een vonnis wordt uitgesproken.
Daar wordt verder geen berekening op gebaseerd. Die moet gebaseerd worden op datumBeginInvul uit tabel procedure (in geval het over spoedprocedure of observatie gaat) en op de vorige einddatum (als het een verlenging is).
 
Bekijk bijlage forum_einddatumtotverlenging1.zip

Tot zover ben ik 'al' geraakt. Ik heb een subquery die de maximale datum berekent van spoedprocedure en observaties.
In oefenquery wordt in het berekend veld de einddatum correct berekend in zoverre het een spoedprocedure, een observatie of een eerste verlenging was.
Nu ga ik op zoek naar een manier om voor de volgende verleningen te bepalen dat ze zich moeten baseren op de einddatum van de vorige. Of dat ze gewoon alle verlengingen die = zijn of < de huidige optellen bij einddatum observatie.
Suggesties?
 
Laatst bewerkt:
OK, het is gelukt. Heb een subquery die de som van # maanden maakt van alle records <= het huidige.
In hoofdquery wordt dit dan in berekend veld opgeteld bij juiste datum.
 
Zou je de oplossing nog in het bestandje van 5 maart kunnen zetten ter lering ende vermaeck van de welwillende lezertjes? Ik kan de oplossing zelf wel maken, maar dat geldt vermoed ik niet voor iedereen :).
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan