Rapport blijft leeg indien niet alle waarden zijn ingevuld

[Johgs]

Op een formulier worden onder andere een aantal namen van medewerkers (max 8) ingevuld naast een aantal andere gegevens per dag. Al deze gegevens staan vervolgens als 1 record in een tabel.

Vervolgens wordt per dag een rapport gegenereerd met al die gegevens waarbij via een tweede tabel met medewerkergegevens een aantal aanvullende gegevens worden aangevuld. Dit werkt prima tenminste, zolang alle 8 velden voor medewerkers zijn ingevuld. Meestal echter hoeven maar 3 of 4 medewerkers ingevuld te worden. Gevolg is dan dat het hele rapport leeg blijft.

Ik kan natuurlijk standaard een dummy medewerker invullen die onzichtbaar is via opmaak, maar er moet een elegantere oplossing zijn.

Ik heb al zitten stoeien met IIf (IsNULL enz) maar het wil niet lukken.

Wat is de beste oplossing hiervoor?

Per medewerker worden in het rapport wat tijden uitgerekend en worden o.a. een personeelsnummer en een bepaalde status toegevoegd.

 

[OctaFish]

Ik kan natuurlijk standaard een dummy medewerker invullen die onzichtbaar is via opmaak, maar er moet een elegantere oplossing zijn.
...
Wat is de beste oplossing hiervoor?

Je tabel is niet genormaliseerd, en dat veroorzaakt alle problemen. Normaliseren dus. En dat betekent, als ik het verhaal lees, de medewerkers(ID) uit je tabel in een subtabel, koppelen op basis van het veld dat je nu in de hoofdtabel gebruikt, en een subformulier gebruiken. Ben je in één keer van alle problemen af.

 

[Johgs]

Ik lees ineens een heleboel nieuwe termen.
Wordt een dagje studeren, weet nu in ieder geval waar, bedankt wederom.

 

[Johgs]

Ik heb de tabel eens laten analyseren, maar opsplitsen in een veelvoud aan tabellen lijkt me geen oplossing. Uiteraard zijn er meerdere medewerkers met een zelfde functie, team, postcode of dergelijke hebben, maar om daar allemaal aparte tabellen voor te maken.....
Even een query gemaakt maar met alleen naam en personeelsnummer en die gekoppeld op de namen in het rapport, dus naam 1 koppelen aan query versie 1, naam 2 aan query versie 2 enz maar dat geeft hetzelfde probleem.
Maar eens met wat subrapporten gaan experimenteren per medewerker.

 

[OctaFish]

Ik vraag me af door wie je de tabel hebt laten analyseren, maar die persoon heeft ofwel (gezien het tijdstip) een glaasje teveel op, ofwel is een Microsoft medewerker . Want een veelvoud aan tabellen? Ik heb het over één tabel... Meer heb je (tenzij de rest van je hoofdtabel ook niet genormaliseerd is) niet nodig voor de oplossing van je probleem.

Uiteraard zijn er meerdere medewerkers met een zelfde functie, team, postcode of dergelijke hebben, maar om daar allemaal aparte tabellen voor te maken.....

Dat is dus echt wel één extra tabel. Nogmaals: bestudeer het onderwerp 'Normaliseren' eens!

 

[Johgs]

Het was in zekere zin een M$ medewerker, want ik liet de analyse over aan Access zelf.
Overigens heb ik geen enkele tabel met dubbele gegevens, behoudens dan dat bijv. de naam van een medewerker in meerdere tabellen kan voorkomen als ingevoerde veldwaarde, maar dat lijkt me onvermijdelijk. Alle persoonlijke gegevens van de medewerker staan in de tabel medewerkers en de naam van de medewerker komt in een tabel met bijv. controlegegevens verzameld door die medewerker in een tabel controlegegevens staan.
Zodra ik in een rapport met die controlegegevens behalve de naam van de medewerker ook bijv. zijn medewerkersnummer nodig heb, koppel ik beide tabellen op "medewerker" en krijg alle gewenste gegevens in het rapport.
Nu wil ik een rapport maken met door medewerkers gerealiseerde uren die geregisteerd staan in tabel 1 en om wat meer gegevens dan alleen de naam van de medewerker (o.a. personeelsnummer) toe te voegen koppel ik de tabel medewerkers. Omdat er meerdere medewerkers per dag zijn voeg ik meerdere versies van de tabel medewerkers toe en koppel die per medewerker. Dit gaat prima zolang alle gekoppelde medewerkerstabellen worden aangesproken. Is er echter 1 veld medewerker in de urentabel niet ingevuld, blijft het rapport leeg.

Voorlopig maar even opgelost door subrapporten in het rapport te gebruiken gebaseerd op een query die voor de betreffende medewerker de aanvullende gegevens opzoekt.

Dat hoofdstuk normalisatie doornemen staat hoog op de agenda. Eerste indruk is dat mijn tabellen goed zijn in die zin dat elk gegeven maar 1x in een tabel voorkomt muv uiteraard de waarden waarmee tabellen gekoppeld kunnen worden.

 

[OctaFish]

Spreek je jezelf niet tegen? In bericht #1:

Op een formulier worden onder andere een aantal namen van medewerkers (max 8) ingevuld naast een aantal andere gegevens per dag. Al deze gegevens staan vervolgens als 1 record in een tabel.

En nu:

Overigens heb ik geen enkele tabel met dubbele gegevens, behoudens dan dat bijv. de naam van een medewerker in meerdere tabellen kan voorkomen als ingevoerde veldwaarde, maar dat lijkt me onvermijdelijk.

Je formulier is dus duidelijk gebaseerd op één tabel met herhalende velden! En dat is nu juist mijn punt: daar moet je één gekoppelde tabel van maken. In die tabel herhaal je dan het HoofdID uit de hoofdtabel, en krijgt elke medewerker dus een eigen record. Ergo: bij 3 medewerkers 3 records, bij 7 medewerkers 7 records. En mocht je dat willen: 53 medewerkers is ook ineens geen enkel probleem meer! Noch voor je formulier, noch voor je rapport.

 

[Johgs]

In die gegevenstabel staan meerdere verschillende medewerkers die ingevuld worden in velden met naam medewerker 1 t/m medewerker 8. Die 8 namen komen wel uit 1 tabel.
Vervolgens worden in het rapport de aanvullende gegevens gezocht in de tabel medewerkers, die dus 8x gekoppeld wordt. medewerker 1 <> medewerkers.1 en medewerker 2 <> medewerkers.2 enz. en dat gaat dus fout als er geen 8 medewerkers betrokken zijn bij die dag.
Maar wat bedoel je met hoofdID? de enige overeenkomende velden in de datatabel en de medewerkerstabel zijn de namen van de medewerkers.

 

[OctaFish]

Volgens mij snap je nog niet helemaal wat normaliseren inhoudt:

In die gegevenstabel staan meerdere verschillende medewerkers die ingevuld worden in velden met naam medewerker 1 t/m medewerker 8. Die 8 namen komen wel uit 1 tabel.

Dit principe (Medewerker1 t/m Medewerker8) zorgt voor je dataredundantie, en zorgt ervoor dat je constructie niet werkt. En die moeten dus uit je tabel, en in een nieuwe tabel.

 

[rmijnten]

Maak een query op basis van de 2 tabellen welke samengevoegd moeten worden, zorg ervoor dat er 1 veld is die altijd uniek is en roep vervolgens het rapport op op basis van het unieke veld ;-)

 

[Johgs]

Ik heb wat te doen met de Pasen. ;-)