[Access+SQL]Datumlijst genereren mbv SQL

[Verwijderd]

Ik wil met behulp van Access een lijst met data (meervoud van datum) genereren aan de hand van twee parameters. Te weten start- en eindweek. Aan de hand van deze lijst kan ik weer waarden vinden en zoniet een 0 (nul) in de plaats ervan zetten. Nu los ik dit op door gewoon de begindatum en de einddatum te bepalen en dan in de data tabel te kijken welke data allemaal voorkomen. 99 Van de 100 keer zal iedere datum in die range terug gegeven worden, maar stel nou dat er geen data wordt ingevoerd. (Bijvoorbeeld met Kerst) dan ontbreken die data.

Nu is mijn vraag. Is het mogelijk om met Access SQL een lijst te genereren van data, ongeacht of die datum voorkomt in ea tabel? En zo ja kan iemand mij dan op weg helpen?

De database is een front-end/back-end Access MDB en ik maak geen gebruik van een Access project. Daar kunnen wel SP ingemaakt worden weet ik. Ik ben gehouden aan de situatie zoals die nu is.

[DeverauX]

Nu is mijn vraag. Is het mogelijk om met Access SQL een lijst te genereren van data, ongeacht of die datum voorkomt in ea tabel? En zo ja kan iemand mij dan op weg helpen?

Je wilt dus zeg maar alle data hebben die zich in een bepaalde week/maand/jaar bevinden? Met access alleen is dat afaik niet mogelijk. Met VBA in combinatie met de functie DateDiff () en DateAdd () zou het wel kunnen, maar dat moet dan wel een mogelijkheid zijn natuurlijk...

[Verwijderd]

Dat is een mogelijkheid, maar ik kan een lijst produceren mbv VBA maar hoe krijg ik dat in de vorm van een queryresult?

[Verwijderd]

Een soortgelijk probleem heb ik ook gehad. Je kunt geen waarden uit querys halen die er niet zijn. Ook geen datums dus. Bij mij was het vrij makkelijk op te lossen omdat ik datums zoiezo moest opslaan in een tabel. Dat kun je deze gewoon met behulp van een For statement generen.
Wil je die niet bestaande datums wel in een tabel opslaan als je ze gegenereerd hebt? of alleen maar als vergelijk. Iets meer info geven, misschien dat we je dan verder kunnen helpen.

[Verwijderd]

Je kunt wel degelijk waardes uit queries halen die er niet zijn, dmv. het casten van waardes als velden.

bv:

code:

select *, cast(1 as integer) as mijnveld from mytable

Echter ik betwijfel of TS op die manier z'n probleem kan oplossen. AFAIK kan wat hij wil niet in Acces SQL.

[Verwijderd]

zowel mijn SQL boek als access als de access helpfile kent geen "Cast()" functie...

Je kunt idd waarden uit tabellen halen die er niet zijn, maar alleen ter hoeveelheid van het aantal records uit een bestaande tabel... voor zover ik weet overigens, want want ik ben geen access goeroe...

[ Voor 57% gewijzigd door Verwijderd op 13-06-2003 16:03 ]

[Verwijderd]

Tijd voor een nieuw boek dus

zonder gekheid, 't is waarsch. geen ANSI-SQL, maar bijna elke zichzelf respecterende SQL-server ondersteund een dergelijke functie. 't beestje kan soms anders heten.

Bewijs:

[Verwijderd]

Nu krijg je net zo veel waarden terug als er records in de tabel rel_persoon zitten. Dit kan in access inderdaad ook (Select ID, Cint(10), Cdate(#01-03-2003# from rel_persoon) maar daarmee heb je het probleem nog niet opgelost. Je kunt op deze manier niet (in access dan) een ander aantal records krijgen als de tabel die je ervoor gebruikt.

[Boss]

Ik begrijp dat je een soort kalender wilt hebben en dan koppelen op datums. Maar de datums zonder gegevens wil je ook weergeven?

Ik zou gewoon 1 tabel maken met daarin 365 records, voor iedere dag van het jaar eentje. Is niet zo netjes, maar wel het enige wat je zo in Access snel aan de praat kan krijgen.

Neemt niet eens zo heel veel ruimte in beslag.

[Verwijderd]

Sorry dat het zolang duurde voordat ik weer eens iets van mij laat horen. Maareh weekend he

Even samenvatten: Cast heb ik niet gevonden in Access, maar ook geen soortgelijke functies. Maar Cast converteert van het ene datatype naar een ander datatype?

Een extra tabel is ook idd niet netjes, dus die optie wilde ik voor het allerlaatst gebruiken. De designer (mijn voorganger) maakt ook gebruik van tijdelijke tabellen en wist de inhoud weer telkens de database groeit als een wezenloos. Dus extra tabellen vind ik niet echt cool.

Meer info: Stel je wilt de performance van een produktiestap weten van week 20. Dan zou ik moeten krijgen:

code:

Datum     aantal       shift
12/5/2003   12             1
13/5/2003   0              1
14/5/2003   15             1
15/5/2003   8              1
16/5/2003   12             1
17/5/2003   13             1
18/5/2003   18             1
12/5/2003   12             2
13/5/2003   10             2
14/5/2003   15             2
15/5/2003   8              2
16/5/2003   0              2
17/5/2003   13             2
18/5/2003   18             2

Dit gaat meestal goed maar wanneer er op een bepaald datum niet is gewerkt in 1 van de 2 shifts dan zal die data niet terug komen. Want die is er niet.

Mijn oplossing is in de datatabel kijken welke datums voorkomen. En die koppelen aan de bovenstaande query en wat de waarde Null heeft een 0 en een shiftnummer meegeven. Dit gaat goed wanneer de de datums voorkomen. Stel nou het is Kerst? Dan wordt er helemaal niet gewerkt en zal er dus ook helemaal geen data bestaan. Toch wil ik die datums uiteindelijk tonen in een grafiek.

Nu heb ik toch iets gevonden op Expert Exchange. Het begint er op te lijken: Dit bieden ze daar als oplossing:

Create a table, tbzMultiply, with one field, Factor, datatype Long.

Add records to this from 1 to the maximum date interval you expect to handle.

Run this query:

SQL:

PARAMETERS DateStart DateTime, DateFinish DateTime;
SELECT DateAdd("d",[Factor]-1,[DateStart]) AS Dates
FROM tbzMultiply
WHERE (((tbzMultiply.Factor)<=DateDiff("d",[DateStart],[DateFinish])+1));

Volgens mij is dit te verbeteren met een functie. Dat ik dus geen brontabel nodig heb maar dat moet ik nog even uitpuzzellen. Of was het nou uitpuzellen? Deze functie zal dus iedere keer een factor moeten terug geven bij een nieuw record. Bij ideeen houd ik mij aanbevolen

[ Voor 20% gewijzigd door Verwijderd op 16-06-2003 11:11 ]

[Verwijderd]

Ik heb de oplossing: Ik maak gebruik van bovenstaande functie en met behulp van code voeg ik de gewenste aantal records toe aan de tabel. Eerst tabelletje leegsmijten vervolgens weer volgooien. Jammer dat Access niet zo'n speciale functie heeft om lijsten te maken. Maar aan de andere kant: gebruik dan ook een volwassen systeem zoals Oracle of SQL server

[Boss]

Dus toch een tijdelijke tabel...

Maar die hoef je toch niet leeg te gooien als je gewoon alle dagen van het jaar er 1-malig in zet?

Of snap ik de bedoeling niet helemaal?

[Verwijderd]

Sinds wanneer gaan we data opslaan die berekend kan worden? Dat noemden Boyce-Codd geloof ik procesgegevens en die filteren we eruit bij het normaliseren.

En ja, zucht, toch een tijdelijke tabel. Kan het ook niet helpen. Mijn kennis schiet in deze te kort om het flexibeler op te lossen.

Wat natuurlijk wel kan is een tijdelijk database tijdens het opstarten aan te maken en dit soort tabellen daarin maken met behulp van een template (die altijd leeg is) en dan koppelen aan je front-end. Dan kan je toevoegen en wegsmijten wat je wilt maar je db zal er niet van exploderen.

Tot slot: Ik blijf het belachelijk vinden dat er niet zo'n functie in Access aanwezig is.

[Stefke]

Ik heb dit al diverse keren geprobeerd op te lossen, maar nog altijd zonder resultaat (nou ja, resultaat is: tijdelijke tabel)

[Verwijderd]

Als er meer zijn met hetzelfde probleem als ik, de tdl tabel, dan heb ik inmiddels het volgende, in theorie, uitgedacht. Zou het mogelijk zijn om in het FROM gedeelte van het SQL statement een functie te plaatsen die een recordset terug geeft. Ik weet dat je een ander SQL statement kan gebruiken in plaats van, bijvoorbeeld, een tabelnaam. Het probleem is alleen dat een query of een tabel niets anders is dan een view op een dataset en een recordset een resultaat van die 'view' Maar om een resultset terug te kunnen geven zou je een tabel moeten hebben of een query, maar die kijkt ook weer naar een tabel en zo zitten we volgens mij in het rondje.

Wie iemand of dit warrige verhaal hierboven kan? Je kan weer wel een stored procedure gebruiken als bron, maar dan had ik dat net zo goed gelijk in het begin kunnen doen. En was deze hele topic overbodig