Verticaal zoeken op een formulier

Status
Niet open voor verdere reacties.

AjaciedNick

Gebruiker
Lid geworden
4 nov 2012
Berichten
129
Bij ons begint excel langzaam iets trager te worden vanwege de vele data. Nu willen we overstappen op acces en zijn daar wat aan het proberen.
Ik heb een formulier waar ik records op kan toevoegen. Nu wil ik dat als je de code van een werknemer invuld hij de naam op gaat zoeken in de tabel Shortlist.
In excel kon dit makkelijk met vert.zoeken, maar hoe doe ik dit in acces?

Wilde hem als bijlage toevoegen om het duidelijk te maken. Maar dan zegt hij ongeldig bestand.
 
Daar was ik al deels achter. Maar welke? en hoe krijg ik die op mijn formulier?
 
Met een query.
Dat is wel een beetje kort door de bocht; Vert.Zoeken als zodanig bestaat niet in Access, en dat vang je dus ook niet met een query op. Wél kun je in een doorlopend formulier (al werkt dezelfde techniek ook op een enkelvoudig formulier, maar dan zie je het minder goed) records opzoeken of filteren. Dat laatste is eigenlijk het mooist, omdat je dan 'live' ziet wat je doet. Zoeken kun je doen met een keuzelijst met invoervak. Die kun je simpel maken met de wizard (let er wel op dat die aan staat). De wizard laat je velden kiezen die je in de keuzelijst wilt zien (daar zoek je dus op) en met een klik op die keuze spring je dan naar het gewenste record. Er hangt overigens wel een query onder die keuzelijst, dus in die zin (vandaar kort door de bocht) heeft Jan wel gelijk.

Live filteren is dus mooier. Ik doe dat zelf door een tekstvak te maken dat is gekoppeld aan een filter op het formulier. In dat tekstvak begin je dan te typen, en met elke letter (of cijfer, dat kan natuurlijk ook) die je toevoegt of verwijdert wordt de selectie kleiner of groter. Ook daar zit dan wel een code achter (de keuzelijst met de wizard maakt overigens een ingebouwde macro) dus er wordt dan wel wat geprogrammeerd.
 
Oh ja: accdb bestanden mag je niet als bijlage meesturen, dat klopt. Maar als je er een zipje van maakt, mag het wel. Bovendien wordt de db dan een stuk kleiner, dus dat helpt ook.
 
Ik heb van alles geprobeerd. De query zoals jan zegt ook, kende ik al, maar dan werkt hij hem niet 'live' bij.
De keuzelijst met invoervak heb ik via de wizard gedaan, maar dan heb ik geen apart veld waar een record weergegeven word?

Bijgevoegd het bestand
 

Bijlagen

  • Driver events.zip
    64,4 KB · Weergaven: 44
Hallo,

Ik gebruik ook zo'n code die ik van Octafish afgekeken/geleend heb.
Deze code staat ook ergens op dit mooie en leerzame forum en doet het prima.:thumb:

Code:
Private Sub Tekst19_Change()
Dim sZzoek As String

    sZzoek = Me.Tekst19.Text
    If Len(sZzoek) > 0 Then
        Me.Filter = "[Employee name] Like ""*" & sZzoek & "*"""
        Me.FilterOn = True
        Me.Tekst19.SelStart = Len(sZzoek)
    Else
        Me.Filter = ""
        Me.FilterOn = False
    End If

End Sub

Succes

Gr. Jan
 
Ik heb de twee besproken varianten even in een formulier gezet, zodat je kan zien wat de werkwijze is. In het tekstvak kun je letters typen op basis van de naam en die filtert dan de lijst. De keuzelijst ernaast laat de lijst intact, maar selecteert het gekozen record. Omdat je het voorbeeldje niet geweldig hebt ingevuld (heel veel lege velden) ziet de keuzelijst er niet goed uit, en de keuzes die je daar maakt dus ook niet, maar het werkt wel.
Je snapt denk ik wel dat ik, als rechtgeaarde Feijenoordfan, je naam heb moeten aanpassen :).
 

Bijlagen

  • 020_nick.zip
    45,7 KB · Weergaven: 51
Dat is niet helemaal hoe ik bedoel.
Ik wil, op een leeg formulier (waar we records toe kunnen voegen), dat als je de code invult je automatisch de naam kunt zien (als je tab doet of in een ander veld klikt).

Ik snap dat je de naam aangepast hebt hoor :)
 
OK, dus als ik het goed begrijp, is de tabel [Shortlist] de tabel met de namen van de medewerkers, en de tabel [Driver events] de datatabel? En wil je in [Driver events] de activiteiten opslaan van de verschillende medewerkers? Dan moet je op zijn minst de tabel [Driver events] opschonen, want daarin zitten nu precies die velden in die je niet mag opslaan, en ontbreekt het veld dat je moet opslaan :). En nu snap ik ook je oorspronkelijke vraag een beetje, want die komt natuurlijk vanuit de Excel achtergrond.

Dus om je denkfout te verhelpen, eerst een stukje theorie. Access werkt dus anders als Excel, waar je VLOOKUP functies meestal wel nodig hebt. In Access dus zelden. In Access gebruik je brontabellen (werknemers, producten, bedrijven/klanten) die de statische gegevens bevatten die niet of zelden gemuteerd worden. Een werknemer bijvoorbeeld voer je één keer in, en daarna verandert zijn naam, geslacht, geboortedatum, indienst datum etc niet meer. Die laatste datum wellicht wel als hij/zij een keer weggaat en opnieuw in dienst komt. Idem dito verandert een product ook nooit: een ingevoerd product krijgt een productcode, een artikelnaam, een categorie etc. en een prijs. Dat laatste gegeven verandert nog wel eens, dus daar moet je een oplossing voor verzinnen. Maar die is er :). In die brontabellen zijn alle records uniek; elke medewerker wordt één keer ingevoerd en krijgt dus een uniek nummer, en in Producten is elk product ook uniek met een uniek nummer. Die unieke velden noemen we sleutelvelden.

OK, dus je hebt je brontabellen; wat ga je daar mee doen? Die gebruik je om transacties vast te leggen. In een winkel is dat verkoop, in een planningsdb zijn dat werkzaamheden. Om bij dat laatste te blijven: een medewerker wordt dus bij een bedrijf gezet voor een bepaalde periode om bepaalde activiteiten uit te voeren. En die wil je vastleggen. Daarvoor moet je dus records maken waarin je de persoon vastlegt, en de handeling. Daarbij geldt: één werknemer kan meerdere transacties uitvoeren, en bij elke transactie hoort één medewerker. Dat laatste bereik je door één veld te hebben voor de MedewerkerID. Je vult in dat veld dus het unieke MedewerkerID in uit de brontabel Medewerkers. Omdat één medewerker meerdere transacties mag invoeren, is in de transactietabel het veld MedewerkerID niet uniek. Tussen de brontabel en de transactietabel bestaat daarom een één-op-veel relatie: één medewerker doet veel transacties.

In jouw voorbeeldje heet die transactietabel [Driver events], en je brontabel [Shortlist]. En één persoon uit [Shortlist] mag dus veel records hebben in [Driver events]. Daarom moet je in [Driver events] dus een veld hebben waarin je het unieke nummer uit [Shortlist] opslaat. En dat is dus het probleem: dat heb je niet. Je hebt in [Shortlist] een veld
Code:
 dat ook in  [Driver events] zit, maar het veld [Code] in [Shortlist] is geen sleutelveld. Sterker nog: het veld is niet eens uniek. Het unieke veld dat je hebt, is het veld [ID]. Maar dat ontbreekt dus in [Driver events]. OK, wat mankeert er nog meer aan [Driver events]? Zoals ik al zei in de inleiding, gegevens in een brontabel veranderen niet snel. Als je de persoonsgegevens wilt kunnen vinden, dan volstaat het om in de tabel [Shortlist] te kijken en het ID nummer op te zoeken. Heb je dat gevonden, dan weet je dus alle naamsgegevens. En dat geldt ook voor de tabel [Driver events]: als je daarin het veld [ID] opslaat, weet je alles wat je nodig hebt. De velden [Code], [Name] [Surname] etc. zijn dus volslagen overbodig in die tabel. We noemen dat: dataredundantie; het opslaan van volstrekt overbodige gegevens. En dat proberen we dus te vermijden in een database. Kortom: die velden moeten er allemaal uit, en moet je vervangen door het veld [ID]. Daarmee is je probleem ook gelijk opgelost.

Hoe gebruik je dit nu op een formulier? Ook simpel! Omdat je personen wilt toevoegen aan transacties, maak je in het formulier fDriverEvents een keuzelijst met invoervak dat je baseert op de tabel [Shortlist]. Die keuzelijst (als je hem met de wizard maakt) gebruik je om alle [I]naamvelden[/I] die je wilt zien als je gaat kiezen te tonen in die keuzelijst. Access zal het [B]sleutelveld[/B] ([ID hier) gebruiken om te koppelen aan het veld [ID] in de tabel [Driver events]. Dat is een stap in het proces; Access vraagt namelijk of je de waarde wilt opslaan voor later gebruik (niet doen) of wilt koppelen aan een veld (Ja dus!). 

En dat is het hele proces: je slaat in [Driver events] dus alleen het veld [ID] op (of CODE als je die als sleutel gebruikt; die heb je al willen koppelen, maar dat lukt nu dus niet) en in de keuzelijst zie je de naamsgegevens die je wilt zien bij het kiezen.

(En we hadden dus allebei een slecht weekend ;). Hoewel: als geboren Hagenees ben ik natuurlijk wel een klein beetje blij :) )
 
Ik begrijp je bericht, maar dat is nog niet de gewenste oplossing.

op [Shortlist] is de code wel uniek, op [driver events] niet, hier komt de code meerdere keren voor. Hier kan een kolom bij waar hij de
Code:
 van [Shortlist] invult als dit nodig is.
Maar dan het formulier, hier kom ik niet uit.

Ik heb nu formulier test aangemaakt. 

Ik wil de code met een keuzelijst kunnen selecteren (of code zelf intypen) en vervolgens tab doen en dat dan de name ingevuld word (de name die bij de code staat in [shortlist])
Als ik dit doe met een keuzelijst met invoervak dan neemt hij de waarde (dus de code die ik intyp) over in het veld wat ik selecteer.

Verder staat in [shortlist] misschien overbodige informatie. Ik wil straks als dit lukt de andere velden ook laten weergeven als de code word geselecteerd.
 

Bijlagen

  • Driver events.zip
    40,5 KB · Weergaven: 37
Laatst bewerkt:
Ik begrijp je bericht, maar dat is nog niet de gewenste oplossing. Op [Shortlist] is de code wel uniek, op [driver events] niet, hier komt de code meerdere keren voor.
Ik vraag me af of je mijn bericht wel snapt, want dat is exact wat ik je vertelde. Ik snap je testformulier ook niet, wat wil je daarmee?

Nogmaals (nu een stuk korter): je hebt een tabel [Driver events]. Daarin wil je koppelen met de tabel [Shortlist]. Dan moet je een koppeling maken tussen het sleutelveld uit [Shortlist] en het gerelateerde veld uit [Driver events]. Dat doe je niet: je koppelt op twee niet-sleutelvelden. Als het veld CODE uniek is, dan moet dat je sleutelveld zijn, niet het veld ID. Dus daar begint het al mee.
De tabel [Shortlist] gebruik je als bron voor de keuzelijst, niet als bron voor het formulier, want dat is de tabel [Driver events]. Dus ofwel je verandert de koppeling, ofwel je neemt een veld ID op in de tabel [Driver events] zodat je wel goed kunt koppelen.

In een keuzelijst kun je verschillende velden laten zien zodat je makkelijker kunt selecteren en de juiste persoon (in dit geval) kunt kiezen. Maar hoe dan ook: je slaat het sleutelveld uit de brontabel op in de gekoppelde tabel. Uiteraard is dat veld in de gekoppelde veld niet uniek, anders kun je elk record uit Shortlist maar één keer gebruiken, en dat is onzin.
In [Driver events] sla je dus verder geen gegevens op uit [Shortlist], alleen het sleutelveld. De rest kun je altijd zien/opzoeken. Wil je op je formulier meer gegevens zien uit de brontabel van de keuzelijst, dan kun je twee dingen doen:
1. alle velden uit [Shortlist] en [Driver events] opnemen in een query, die opslaan en die query als bron gebruiken voor je formulier. Je kunt dan alle velden uit [Shortlist] zien als je de keuzelijst gebruikt om een CODE te kiezen.
2. De gegevens uit de keuzelijst halen en in een niet-gebonden tekstveld op het formulier zetten.

Optie 1 heeft voor- en nadelen. Voordeel is dat je de velden snel en makkelijk op het formulier zet; ze staan gewoon in de lijst met velden. Nadeel: je kunt die velden in beginsel muteren, dus per ongeluk veranderen. Meestal wil je dat niet.
Optie 2 is een klein beetje lastiger om te maken, maar wel veel veiliger omdat je niets kunt veranderen aan de opgehaalde gegevens.

Zet in je testformulier maar eens twee tekstvakken neer, en geef ze deze formule als Besturingselementbron: =[Keuzelijst5].[column](1) en =[Keuzelijst5].[column](2).
 
Het werkt nu top. Dan komt de naam wel tevoorschijn en slaat hij op in [Driver events] alleen de code slaat hij niet op
 
Laatst bewerkt:
Dan heb je de keuzelijst waarschijnlijk niet aan het veld gekoppeld.
 
Ik heb nu dat de code meegenomen word. en bij [employee name] de besturingselement code veranderd naar =[Keuzelijst5].[column](1) maar kan ik hem dan op een of andere manier nog meenemen?

bijlage is niet meer van toepassing.
 

Bijlagen

  • Naamloos.png
    Naamloos.png
    10,5 KB · Weergaven: 66
Laatst bewerkt:
En waarom zou je dat willen? Ik heb al eerder uitgelegd dat je dat dus nooit doet, en zeker niet bij gegevens die nooit veranderen. Volslagen onnodig om dat te doen, en zorgt alleen maar voor dataredundantie.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan