Lookup en relatie ?

[Carloj]

Ik heb een gevaren level die gekoppeld is aan een combo box. Als je dus bepaalde dingen invoert komt er een gevaren level uit bijv. 4 . Nou wordt dat level opgezocht met een Dlookup formule. Maar het resultaat wat er uit de formule komt moet ook in een andere tabel komen.
de formule is :
=DLookUp("[GevaarLevel]";"Onderdelen";"[OnderdelenID] = " & [Formulieren]![Data_test]![cboOnderdeel_naam])
het resultaat van die formule wordt uit de tabel onderdelen gehaald. Maar de uitkomst moet ook in een tabel komen waar alle data wordt opgeslagen.
Zou het dus mogelijk zijn om die formule in besturingselementbron te zetten en het getal wat er uit komt in een andere tabel ?

Dit mag trouwens ook allemaal "backstage" gebeuren dus de eind gebruiker hoeft niet perse het gevaren level te zien.

 

[OctaFish]

Ik snap niet helemaal waarom je de waarden die je met een Lookup ophaalt uit de ene tabel wilt opslaan in een andere. Dat riekt als dataredundantie, en dat moet je niet willen in je database. Overigens zou ik nooit DLookup gebruiken, maar de velden uit de keuzelijst halen. Sneller en makkelijker.

 

[Carloj]

De eindgebruiker mag het gevaren level niet aanpassen, dus hij moet ergens vandaan komen. En later heb ik dit ook nodig bij telefoon nummers van werknemers. Deze moeten ook uit een andere tabel komen daarna in een form weergegeven worden en daarna weer in een andere tabel terecht komen.

 

[OctaFish]

De eindgebruiker kán het level niet aanpassen als je de waarde in je keuzelijst hebt zitten.

Ik heb een gevaren level die gekoppeld is aan een combo box.

In het tekstvak zet je dan deze formule bij Besturingselementbron:

=cboOnderdeel_naam.Column(2)

Er in bovenstaand voorbeeld vanuit gaande dat het Level in je Rijbron van de keuzelijst de derde kolom is. Dat kan uiteraard elke andere kolom zijn. Door deze constructie te gebruiken heb je de DLookup niet nodig, en de gebruiker kan niets veranderen. Want de waarde komt uit een bron waar hij/zij niet bij kan, anders dan via de keuzelijst.
Alles wat je wilt ("later heb ik dit ook nodig bij telefoon nummers van werknemers") kun je met queries bereiken. Nergens voor nodig dus om dat steeds weer in tabellen op te slaan.

 

[Carloj]

Dit snap ik niet helemaal.
Even wat meer info van mijn kant. Ik ben een meldingssysteem aan het maken. Hierin kan een werknemer een melding maken. Deze melding moet opgeslagen worden in een tabel met de naam van de melder, datum enz. Dan wordt vanuit die tabel een rapport gemaakt waarin komt te staan wat er die week gemeld is. Dit rapport gaat naar de technische dienst die deze meldingen gaat verhelpen. Als de TD een melding heeft gemaakt dan wordt deze ook weer in een form ingevuld met het meldingsnummer , wie heeft het gemaakt, hoe heeft die het gemaakt enz. Dit moet ook weer in een aparte tabel komen omdat hier weer verschillende gegevens uitgehaald moeten worden.
Maar omdat dit door meerder mensen gebruikt gaat worden en er een koppeling wordt gemaakt met een ander programma moet de keuzes die ingevoerd kunnen worden beperkt worden.
Hierbij een voorbeeld.
Het telefoon nummer wordt uit tabel werknemers gehaald en in het form gezet maar nu moet dat telefoonnummer ook in de tabel data meldingen komen te staan.

Alvast bedankt voor je hulp!

 

[OctaFish]

Is er een reden waarom je mijn volledige bericht hebt gequoot? Staat er niet voor niks pal boven . Graag de quote dus verwijderen, want het lijkt mij niet echt zinvol, en bovendien zijn quoots ook niet beter leesbaar dan het origineel. Wanneer gebruik je een quote? Bijvoorbeeld nu:

Dit moet ook weer in een aparte tabel komen omdat hier weer verschillende gegevens uitgehaald moeten worden.

Dit snap ik namelijk niet: ik ben zelf beheerder van een meldingensysteem (weliswaar niet in Access gemaakt ) dus ik weet wel iets af van incidentenbeheer. En bij ons werkt iedereen gewoon in één en dezelfde tabel. Waar dan uiteraard koppelingen in zitten met andere tabellen. Zo heb je per melding meestal meerdere activiteiten die geregistreerd moeten worden, en daarvoor gebruik je dan een gekoppelde tabel. Wij leggen ook de emails die verstuurd en ontvangen worden per melding vast, dus dat is ook weer een gekoppelde tabel. Voor de gebruikers heb je maar één veld nodig, want als je het MedewerkerID weet, kun je alles ophalen in de tabel Medewerker, en daar haal je dan dus het telefoonnummer vandaan. Rapporten kun je altijd maken op basis van alle gekoppelde tabellen, en ik zie dus niet waarom je daar aparte tabellen voor gebruikt.

Aan de behandelaarskant en gebruikerskant heb je uiteraard ook verschillende formulieren en rechten nodig. Een behandelaar moet nu eenmaal andere dingen doen/zien dan een gebruiker die alleen maar meldingen hoeft te kunnen maken en inzien. Eventueel nog afmelden. Een telefoonnummer extra opslaan is doorgaans dus ook helemaal niet nodig, tenzij het zo vaak voorkomt dat iemand niet op zijn eigen nummer bereikbaar is dat je een apart nummer wilt kunnen vastleggen. In dat geval is een los veld in de meldingen tabel prima te gebruiken. Maar dit vul je dan alleen in als de gebruiker zelf aangeeft dat hij (al dan niet tijdelijk) niet op zijn eigen nummer bereikbaar is.

 

[Carloj]

Sorry, ik was deze nog vergeten toe te voegen.Bekijk bijlage Database7-accdb.zip

 

[OctaFish]

Ik heb ter lering ende vermaeck jouw veld met de DLookup laten staan, en er een veld bijgezet (ook trouwens de keuzelijst moeten aanpassen) dat het telefoonnummer uit de keuzelijst haalt. Let ook op de snelheidsverschillen waarmee het nummer wordt getoond . En dan zitten er nog maar drie werknemers in je tabel!

 

[Carloj]

Alleen zou die het telefoon nummer nu ook bij de meldingen moeten zetten.
Is dit mogelijk ?

 

[OctaFish]

Je leest mijn berichtjes geloof ik niet goed . Nergens voor nodig als je de db goed opzet. Gebruik een apart tekstvak als je een afwijkend telefoonnummer nodig hebt.

 

[Carloj]

Ik snap nog niet wat je bedoeld.

 

[OctaFish]

Je kunt best een veld [Telefoonnummer] in je tabel [Meldingen] zetten, maar dat hoef je niet te vullen. Mag de gebruiker doen.