ACCESS VBA : Bijkomende filter op formulier.

Status
Niet open voor verdere reacties.
F

fde

Gebruiker
Lid geworden
31 aug 2017
Berichten
110
Ik wil een bijkomende filter te plaatsen op mijn zoekformulier frm_sollicitant_zoek_functie. Dit is een doorlopend formulier waarvan de rijbron qry_sollicitant is.

Zie print-screen.

Knipsel.PNG

De bedoeling is:
Als uit de keuzelijst "functie" een item wordt gekozen er de mogelijkheid dient te zijn dat van die gekozen "functie" er een verdere selectie dient/mag te gebeuren per "Provincie" voor verdere verfijning van de filter.

De keuzelijst cboFunctie heeft als rijbron tbl_functie en de cboProvincie heeft als rijbron tbl_postcode.
Beide keuzelijsten (met invoervak) werken perfect.

Code: 
Private Sub cboZoekFunctie_AfterUpdate()
    Me.Filter = "[ZOEKEN] like ""*" & Me.cboZoekFunctie & "*"""
    Me.FilterOn = True
End Sub

Private Sub cboZoekProvincie_AfterUpdate()
    Me.Filter = "[PROVINCIE_SOLLICITANT] = """ & Me.cboZoekProvincie & """"
    Me.FilterOn = True
End Sub

Ik heb verschillende oplossingen gevonden en uitgeprobeert doch geen enkele werkt.
Kan iemand me hiermee op weghelpen aub.
 
Laatst bewerkt:
Jammer genoeg niet hellboy01.
Alleen het feit dat de recordbron (in het filmpje) voor de twee keuzelijsten uit één en dezelfde tabel, terwijl in mijn geval dit 2 totaal andere recordbronnen "tbl_postcode" en "tbl_functie" . Deze 2 tabellen zijn onderling niet linkbaar. Dus ik denk dat de functie " .requiry" geen soelaas brengt.
 
Maar dan begrijp ik niet wat jij wilt als er geen relatie bestaat tussen de twee tabellen????
 
maak eens een screen print van de relaties tussen de tabellen. Ik weet niet meer hoe je dat ook alweer kon laten zien maar google dat maar. Dan hoef je ook geen file in te sturen dan kan je de tabellen en velden en de relaties er tussen in een keer zien en dan praat dat wat makkelijker.
 
Het probleem heeft (uiteraard) niks met relaties te maken, maar alles met het filter. Zodra je meerdere velden gaat combineren, moet je het filter daarop aanpassen. TS doet dat niet in zijn oorspronkelijke code, daar kijkt hij alleen naar de zelfstandige keuzelijsten. Ik gebruik zelf een uitgebreide functie die filters samenstelt, zeker als je er heel veel hebt waarop gefilterd kan worden. Zijn het er twee of drie, dan kan je het filter nog wel per keuzelijst maken en gebruiken. In het geval van TS zouden de filters er dan zo uitzien:
Code: 
Private Sub cboZoekFunctie_AfterUpdate()
Dim sFilter As String, bF As Boolean

    If Me.cboZoekFunctie = vbNullString Then
        If Me.cboZoekProvincie = vbNullString Then
            bF = False
        Else
            sFilter = "[PROVINCIE_SOLLICITANT] = """ & Me.cboZoekProvincie & """"
            bF = True
        End If
    Else
        sFilter = "[ZOEKEN] = """ & Me.cboZoekFunctie & """"
        If Not Me.cboZoekProvincie = vbNullString Then
            sFilter = sFilter & " AND [PROVINCIE_SOLLICITANT] = """ & Me.cboZoekProvincie & """"
            bF = True
        End If
        bF = True
    End If
    Me.Filter = sFilter
    Me.FilterOn = bF
End Sub

Code: 
Private Sub cboZoekProvincie_AfterUpdate()
Dim sFilter As String, bF As Boolean

    If Me.cboZoekProvincie = vbNullString Then
        If Me.cboZoekFunctie = vbNullString Then
            bF = False
        Else
            sFilter = "[ZOEKEN] = """ & Me.cboZoekFunctie & """"
            bF = True
        End If
    Else
        sFilter = "[PROVINCIE_SOLLICITANT] = """ & Me.cboZoekProvincie & """"
        If Not Me.cboZoekFunctie = vbNullString Then
            sFilter = sFilter & " AND [ZOEKEN] = """ & Me.cboZoekFunctie & """"
            bF = True
        End If
        bF = True
    End If
    Me.Filter = sFilter
    Me.FilterOn = bF
End Sub

Je snapt hopelijk wel dat deze constructie naarmate er meer velden bijkomen waarop je wilt filteren, er niet makkelijker op wordt.
@TS: Je krijgt (van mij althans) sneller antwoord als je de vraag in het Access forum stelt, want dat bekijk ik sneller en vaker :).
 
Inderdaad OctaFish deze code werkt.

Heb wel jouw codes: ....."[ZOEKEN] = """ & Me.cboZoekFunctie & """" aangepast naar ...... "[ZOEKEN] LIKE ""*" & Me.cboZoekFunctie & "*""" vanwege dat de zoekstring over vier kolommen gaat.

Ik zal in het vervolg m'n vragen in het Access-forum-gedeelte plaatsen.

Hartelijk dank voor de oplossing.
 
Laatst bewerkt:
fde zei:
... aangepast naar ...... "[ZOEKEN] LIKE ""*" & Me.cboZoekFunctie & "*""" vanwege dat de zoekstring over vier kolommen gaat.
Klik om te vergroten...
Dit vind ik vreemd en onlogisch. Zoeken in een keuzelijst (met invoervak) doe je altijd op de complete geselecteerde waarde uit die keuzelijst. LIKE is dus zinloos, want je zoekveld wordt vergeleken met de complete keuzelijstwaarde. De twee zijn identiek. Het heeft alleen zin om met LIKE te werken als je in een deel van de tekst zoekt. Dus je zoekt in een veld met stedennamen, en je keuzelijst laat dingen zien als "mste". Dan wil je wellicht zowel Heemstede als Amsterdam kunnen vinden. Maar ik zet er mijn geld op dat je keuzelijst in dat geval de complete plaatsnamen laat zien, en dan is de zoekstring LIKE "Heemstede" identiek aan ="Heemstede". Ik gebruik een LIKE dus alleen als ik live filter m.b.v. een tekstvak waarin ik filter in een deel van een veld. Nooit met een keuzelijst.
Je bewering dat je met deze code over 4 kolommen zoekt is m.i. al helemaal fout. Je gebruikt je keuzelijst om te zoeken in een veld, niet andersom. Je zou dan voor elke kolom uit de keuzelijst een aparte string moeten maken. Overigens vind ik heel apart dat je in één keuzelijst 4 kolommen hebt die in essentie allemaal stukjes bevatten (waarom anders de LIKE?) uit één veld. Dat zou ik graag eens van dichtbij willen zien!
 
In dit geval heb je het goed neergeschreven; het veld [Zoeken] is, neem ik aan, nog steeds een samengesteld veld op basis van een aantal andere velden die je combineert. En je keuzelijst is dus één waarde die ergens in die zoekstring voorkomt. Dus je moet nu inderdaad met LIKE zoeken, anders vind je niks. Je hoeft je overigens niet te verontschuldigen, want jij weet (hopelijk) beter wat je doet dan ik, omdat jij de db hebt en kent, en ik niet. Ik ben afhankelijk van de kruimeltjes die je ons toewerpt :).

Wat betreft die samengestelde string: in het andere draadje stelde ik dit voor.
Code: 
ZOEKEN: [FUNCTIE1_SOLLICITANT] & [FUNCTIE2_SOLLICITANT] & [FUNCTIE3_SOLLICITANT]

Dat werkt in beginsel wel, maar kan toch onverwachte zoekresultaten opleven. Stel dat ik een aantal namen combineer: "Snodaard", "Boomhakker" en "Jansen" (wordt: "SnodaardBoomhakkerJansen"). En een string met "Vliegen", "Mepper" en "Aardboom" (wordt: "VliegenMepperAardboom"). Alle losse namen staan ook in de keuzelijst, dus je wilt kunnen zoeken op Snodaard, Jansen etc. Als je nu "Aardboom" kiest in de keuzelijst, dan krijg je niet één, maar twee resultaten. Je vindt namelijk óók deze naam: "SnodaardBoomhakkerJansen". En dat is dus eigenlijk niet de bedoeling, want je combineert hier twee namen tot één naam. Dat kun je voorkomen door de zoekstring te veranderen in:
Code: 
ZOEKEN: [FUNCTIE1_SOLLICITANT] & "|" & [FUNCTIE2_SOLLICITANT] & "|" & [FUNCTIE3_SOLLICITANT]
Nu is de combi veranderd in "aard|boom" en wordt deze dus niet meer gevonden. Je zoekt uiteraard nog steeds met LIKE want de zoekwaarde is alleen te vinden in een grotere string. Maar het resultaat is nauwkeuriger.
 
Met dank voor de verdere "fine-tuning" en bijhorende uitleg waarom.

Als ik een vraag neerpoot probeer ik dat zo compleet mogelijk te doen; indien nodig met print-screens. Zo blijven het geen kruimels :) !
De mdb file opladen kan ik echt niet maken daar het hier over persoonlijke- en contactgegevens gaat van meer dan 4000 personen en deze groeit dagdagelijks.

Maar dat ik hulp nodig heb dat is een feit daar ik in weze absoluut geen programmeur ben maar wel weet waarover het gaat. M.a.w. ik probeer het gestroomlijnd en meer geautomatiseerd te krijgen in plaats van op de oude manier te werken met "37" verschillende excel-files.
 
Laatst bewerkt:
Je zou, als je vaker vragen over een db hebt, een kopie kunnen maken en die vullen met dummy gegevens. We hebben voor het constateren/oplossen van een vraag doorgaans maar een paar records nodig, dus dat kan niet zo'n probleem zijn. Kwestie van de tabellen een keer leeg gooien met een procedure, en dus wat records inkloppen. Sowieso handig om te hebben als je nieuwe functies gaat maken/testen!
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan