lege velden weergeven in rapport via kruistabel

Situatie: een rapport dat een overzicht geeft van inspectiebezoeken per jaar.

Hiervoor heb ik als brongegevens een query met een kruistabel gemaakt die zijn data uit verschillende databanken haalt. Één met de firmagegevens, één met de resultaten van de inspectiebezoeken en één met de ID’s van de inspecteurs.
Bedoeling is dat het rapport enkel die gegevens weergeeft van de firma’s die aan een bepaalde voorwaarden voldoen. (combinatie van 2 True/false velden in de tabel met de firmagegevens)

Probleem is nu dat er in de kruistabel, en dus het rapport, enkel gegevens worden weergegeven van de inspectiebezoeken waar al waarden zijn ingevuld. Er moet dus al een inspectiebezoek hebben plaatsgevonden en de inspecteur moet bepaald zijn. Geplande, lees voldoen aan de criteria van de 2 true/false, werkt dus niet want worden nog niet als lege velden weergegeven. Ook de firmanaam, als deze voor de eerste keer gebruikt wordt, wordt niet getoond.
Nu moet ik dus in het begin van het jaar alle firma’s overlopen en zet ik bij diegene die een inspectie moeten krijgen de waarde 1 en kies een inspecteur om ze al in het rapport zichtbaar te maken.

Kan ik dit op een andere manier oplossen zodat dit automatisch loopt vanaf mijn 2 true/false voorwaarden zijn voldaan en de firma dan, weliswaar zonder gegevens of inspecteur wel al zichtbaar wordt in mijn rapport.

In bijlage een voorbeeld van de opbouw van de query en het rapport.

Alvast bedankt voor de hulp aan deze doe het zelf accesliefhebber.

Marc

Je plaatjes zeggen niet zoveel, maar het probleem is duidelijk genoeg om zonder afbeeldingen op te lossen. Je gebruikt nu queries op basis van een zgn. Inner Join: alleen records laten zien waarvan het koppelveld in beide tabellen voorkomt. Dus alleen een leverancier als er een inspectie is geweest. Je vraagstelling is echter anders: je wilt alle leveranciers zien (doe voldoen aan je criterium), ongeacht of er een inspectie is geweest. En dat kan, door de relatie tussen de tabellen aan te passen in je query. Daarvoor moet je op de lijn tussen de twee tabellen klikken, en niet optie 1 kiezen, maar 2 of 3. Welke is nooit goed te voorspellen . Ik schat optie 2. In ieder geval de optie waarbij je van de tabel alle leveranciers ziet, en de gekoppelde inspecties. Zou je de andere optie kiezen, dan verandert er namelijk niet zoveel, omdat je sowieso alleen maar leveranciers in je tabel tInspecties hebt van bestaande leveranciers.

Om dat even te verduidelijken: stel je hebt 5 leveranciers, genummerd 1 t/m 5. Daarvan hebben 1, 3 en 5 een inspectie gehad. In de tabel tInspecties heb je dan records met daarin de leveranciers 1, 3 en 5. Het kan zijn dat er meerdere inspecties zijn geweest, dat maakt voor het verhaal niet uit.
Leveranciers 2 en 4 hebben nog geen inspectie gehad, dus die staan niet in tInspecties. Een query met (standaard) optie 1 laat dus alleen leverancier 1,3 en 5 zien. Want die zitten in tInspecties. Verander je de query naar optie 2 (alle leveranciers) dan zie je in je query alle leveranciersgegevens, en alleen van leveranciers 1, 3 en 5 ook de inspectiegegevens. Kies je optie 3 (alle inspecties) dan zie je alleen de leveranciers 1, 3 en 5 terug in je query, want 2 en 4 hebben geen inspectie gehad. In dit voorbeeld is optie 3 dus gelijk aan optie 1.

Ik hoop dat het zo wat duidelijker wordt .

Octafish,

Bedankt voor je snelle reactie maar dan krijg ik volgende foutmelding (bij wijziging van de relatie tussen de twee databanken TBlFirma en TblGegevensWerfControle) zie bijlage

Wat zou ik dan in die andere query eerst moeten uitvoeren en hoe kan ik nadien beide bij elkaar brengen?

mvg

Marc

Ik kan je bijlage bijlage niet openen, dus je zult wat meer moeten vertellen. Het kan bijvoorbeeld om het gegevenstype gaan, of om integriteit problemen. Die moet je dan eerst oplossen.

Met de bijlage bedoelde ik de printscreen van mijn wijzigingen in de queryopbouw met de foutmelding.

Dat snap ik, maar ik weet nu nog niet wat de foutmelding is

Die staat onderaan op de printscreen maar zal hem even weergeven:
De SQL-instructie kan niet worden uitgevoerd omdat deze niet-eenduidige outer joins bevat.Als u een van de joins als eerste wil uitvoeren, maakt u een anderequey die eerste join uitvoert en neemt u die query op in uw SQL instructie.
Deze foutmelding komt als ik de query wil laten lopen nadat ik één van de relaties op 2 of 3 gezet heb zoals je voorstelde.

Heb er even over nagedacht en denk dat de reden wel eens kan zijn dat ik twee zaken tegelijk vraag:
- koppeling tussen firma en alle jaarlijkse resultaten van de inspectiebezoeken
- koppeling tussen al die inspectiebezoeken en hun inspecteur

heb dit nu in 2 queries geplaatst waarbij de eerste (met tabel firma's en tabel resultaten) als bron gebruikt wordt in de tweede (Query 1 en tebel inspecteurs)

Dit lijkt wel te werken maar geeft wel wat vertraging omdat er in mijn rapport ook nog met conditional formating wordt gewerkt in de kleurweergave van de resultaten (boven of onder het gemiddelde).
Zit ik met deze redenering juist denk je of heb je nog andere voorstellen omdat je ook spreekt over gegevenstype en integriteit.

Ik vind acces fascinerend maar moeilijk om goede info te vinden als beginneling. Mijn apreciatie gaat dan ook zeker naar mensen zoals u die de tijd willen vrijmaken om ons te helpen. Bedankt!
marc

Hallo, de foutmelding komt omdat de tabel waarnaar een outer join gaat verder naar een andere tabel gekoppeld wordt. Alhoewel dit in gewone SQL geen problemen geeft, krijg je in access wel een foutmelding omdat deze niet weet welke join eerst moet uitgevoerd worden. De oplossing voor Access is inderdaad om die in 2 queries te plaatsen. Dan wordt de outer join in de inner query eerst uitgevoerd en daarna deze in de bovenliggende query.

Om de beginselen te doorgronden kun je de cursus in de Handleidingen sectie eens doorlopen; dan kom je al een heel eind. En anders stel je de auteur hier gewoon nog een vraag .

Voor query-optimalisatie:

MINT zei:

heb dit nu in 2 queries geplaatst waarbij de eerste (met tabel firma's en tabel resultaten) als bron gebruikt wordt in de tweede (Query 1 en tebel inspecteurs)

Klik om te vergroten...

Ik vind je oorspronkelijke query nogal onhandig, en ik denk dat het wellicht slimmer is om je db (met anonieme data) te plaatsen, want het lijkt mij een hele simpele vraag, met een hele simpele oplossing. Die zou in ieder geval géén sloom rapport hoeven op te leveren.