MsAccess: Hoe kan ik Tabbellen combineren met een brontabel met soms lege waarden

Status
Niet open voor verdere reacties.

Mimi1981

Nieuwe gebruiker
Lid geworden
9 mei 2016
Berichten
4
Ik probeer 2 tabellen in MsAccess te combineren. Mijn brontabel bevat voor veel regels een personeelsnummer, maar niet alle mutaties bevatten een personeelsnummer. Nu koppel ik dit personeelsnummer aan een HR tabel om de naam van de personeelsleden te achterhalen. Omdat ik in de brontabel niet voor elke regel een personeelsnummer heb, krijg ik niet alle waarden te zien na de koppeling. WIe kan mij hierbij helpen?
 
Even samenvatten: je hebt eigen tabellen ('brontabel' en 'Mutaties') in Access en een gekoppelde tabel ('HR tabel'). In de Mutaties heb je niet altijd een Personeelsnummer, maar wel mutaties. En nu wil je alle mutaties kunnen koppelen aan een persoon?
Dat wordt een beetje lastig, zeker omdat je niet teveel informatie geeft. In beginsel zou de situatie natuurlijk niet voor mogen komen; alle mutaties zouden een PersID moeten hebben. Dat zou afgedwongen moeten zijn in de Relaties. Als je de situatie straks gerectificeerd hebt, zou ik dat ook gelijk doen om toekomstige problemen te voorkomen. Maar voordat je dat kan doen moet je dus eerst de ontbrekende PersID's invullen.

Hoe kun je te werk gaan? Zoals ik al zei geeft je wat te weinig informatie.

Mijn brontabel bevat voor veel regels een personeelsnummer, maar niet alle mutaties bevatten een personeelsnummer.
Heb je in je brontabel voor elk personeelslid een personeelsnummer? Of ontbreken ze alleen bij sommige records in de mutaties?
In essentie is het niet zo moeilijk als het om ontbrekende personeelsnummers in de brontabel gaat. Je zult dan een match moeten maken op ándere gegevens uit de brontabel. Ik doe dat dan door velden te combineren in één veld. Bijvoorbeeld de velden Achternaam, Voornaam (en/of Voorletters) en Tussenvoegsel. Dezelfde constructie moet je ook kunnen maken met de gegevens uit de HR tabel, al hoeven daar de veldnamen niet hetzelfde te zijn. Als de output maar identiek is.

Welke combinatie je moet maken hangt dan af van de hoeveelheid records in je tabel. In een bedrijf met 20 werknemers is de kans dat je 2 'Jan Janssen's hebt een stuk kleiner dan in een bedrijf van 2000 mensen. Om te controleren of je dubbele vergelijkingsvelden hebt, kun je een query maken met alleen dit samengestelde veld, waarbij je groepeert op dit veld en op een ander veld de functie <Aantal> zet. Als het goed is, heb je voor elke combinatie dan maar één record. Die query kun je dan nog filteren op het criterium >1 zodat je heel snel de unieke namen (die dus goed zijn) niet ziet, en de dubbele namen wél. Uiteraard moet de query leeg zijn als je hem uitvoert, ten teken dat alle naamcombinaties uniek zijn.
Als dat niet zo is, moet je het veld dus uitbreiden. Welk veld je dán toevoegt, kan ik zo niet zeggen, want ik weet niet wat je opslaat in je db. Heb je bijvoorbeeld de geboortedatum (een logisch gegeven om te hebben in een HR) dan kun je die er bij zetten; "Jan Janssen_11-03-1982" is dan niet hetzelfde als "Jan Janssen_27-01-1987". En daarmee is de combinatie weer uniek en dus geschikt.

Als je de unieke combinatie hebt kunnen maken, kun je hem in een query gebruiken om de Brontabel te matchen met de HR tabel. Die 2 tabellen koppel je nu aan elkaar (op basis van PersID) maar die koppeling moet dus weg. De 2 tabellen ga je namelijk koppelen op basis van een criterium. Daarbij gebruik je de eerder gemaakt formule als veld en de overeenkomende variant uit de HR tabel als criterium. Als je dan de velden Personeelsnummer uit beide tabellen ook in het raster zet, krijg je een keurig overzicht van de personen in je Brontabel met de bijbehorende Personeelsnummers. Die dus uit de HR tabel komen.

De vervolgstap zou dan bij mij zijn om de brontabel bij te werken met de op deze manier verkregen personeelsnummers. Kwestie van de selectiequery omzetten naar een Bijwerkquery en het veld Personeelsnummer vullen vanuit de HR tabel. Ik zou dan nog wel filteren op de lege velden in de brontabel, om te voorkomen dat je de bestaande personeelsnummers vervangt. Dat hoeft niet, omdat je die a) al hebt en b) je query er trager van wordt. Je wilt immers alleen de lege records bijwerken.
En daarna dus de relatie tussen Brontabel en Mutaties aanpassen!
 
Allereerst bedankt voor je reactie. Het zit iets anders in elkaar. Mijn brontabel bevat verschillende typen mutaties. Sommige mutaties worden door personeelsleden aangemaakt en andere zijn algemene kosten zonder personeelsnummer. Op deze regel is het personeelsnummer 0 ipv bijv 101010. Nu moet ik de namen van de personeelnummers aan deze brontabel koppelen. Dus doe ik dat obv het nummer in het brontabel en het nummer uit de hr tabel. Mijn mutatietabel bevat voor 1 periode 75000 regels. En als ik deze koppel aan de hr tabel heb ik veel minder. Dit komt oa doordat sommige regels in mijn brontabel als personeelsnummer waarde 0 hebben en die bestaat niet in mijn hr tabel.
 
Ik snap nu even niet wat je aan het doen bent. Er is dus maar één tabel? En dat is geen persoonstabel, maar een mutatietabel met verschillende soorten mutaties? En daarbij heb je dan niet altijd een geldig PersoonsID, maar ook records met PersoonsID 0?
 
1 mutatietabel met mutaties met en zonder personeelsnummer. Dit is een export vanuit SAP. mutaties zonder personeelsnummer worden hier met een 0 gevuld. Daarnaast heb ik dus een HR brontabel met personeelsnummers en namen etc. EN die koppel ik aan elkaar om de naam aan de mutatietabel toe te kunnen voegen. maar als ik dit doe, bevat mijn query minder resultaten dan wat in de mutatietabel staat.
 
Dan snap ik het goed, en zie ik zo gauw niet hoe je dat op kunt lossen. Als er in het PersID veld een 0 staat, op basis waarvan wil je dan achterhalen voor welke persoon de mutatie is geweest? Is m.i. onmogelijk. En je geeft zelf al aan dat het om mutaties gaat die algemene kosten betreffen. Als je ze wel wilt zien in de verzamelquery, dan kun je de relatie tussen Mutaties en HR omzetten naar een Outer Join waarbij je alle records ziet uit Mutaties, en alleen de gekoppelde persoonsrecords uit HR. Ik vermoed dat je dat wilt zien....
 
Dat is inderdaad wat ik wil zien. EVen uitvogelen hoe een outer join werkt.
 
Spoiler alert :D
Dubbelklikken op de relatielijn tussen de twee tabellen, en optie 2 of 3 nemen. Afhankelijk van de opties die je ziet. Zolang je maar kiest voor wat ik in #6 heb geschreven.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan