Query exporteren met aangepaste criteria

Goededag,

In mijn Access-bestand heb ik een Startform, die functioneert als hoofdmenu. Op die Startform bevinden zich knoppen om een andere Forms te openen.
Er bevinden zich op deze Form ook knoppen die met een druk op de knop een query opslaan als excel. Dat werkt met de code hier onder:

Private Sub CommandExportQuerynaam_Click()
DoCmd.OutputTo acOutputQuery, "Querynaam", acFormatXLSX, "c:\Test\Bestandsnaam.xlsx"
End Sub

Klik om te vergroten...

En nu mijn vraag:
Hoe kan ik de Criteria van de query aanpassen aan de hand van wat zich in textbox(en) wordt ingevuld door de gebruiker (zonder de query te openen en het handmatig in te voeren)?
Textbox 1 & textbox 2 in de Startform zijn bijv datums waarbinnen de query de resultaten moet tonen. (groter dan de ene, kleiner of gelijk dan de andere). De datums in de query staan bijvoorbeeld in de 2e kolom in de query. Column(1) heet dat dan? Of werkt dat niet zo met querries?

Manier 1:
Hoe kan ik QueryCriteria met zo'n textbox linken? Kan dat überhaupt? Moet de textbox in de Startform dan een veld in een tabel vullen en kan deze waarde dan gebruikt worden in querycriteria van een kolom?
In Excel zou ik dan in de query in het criteriaveld iets hebben gezegd als "=A1". Maar ik weet niet hoe dat in Access zou moeten.

Manier 2: of kan/moet die aanpassing van het criteria gedaan worden in de code die aan de knop gekoppeld is?
Moet de code misschien zo werken dat de code 'handmatig' de tekst in het querycriterium van een kolom vervangt door iets anders, deze query 'refreshed' en dan opslaat als excel? Zoiets? En dit zonder dat de query zichtbaar wordt geopend.

Het is mijn eerste Access-creatie, ik zou het waarderen als mensen die me willen helpen in hun achterhoofd houden dat ik beperkte kennis heb en een uitleg iets uitgebreider doen dan normaal.
Bij voorbaat dank!

Je kan de query definitie aanpassen met de waarden uit de text boxes, maar daar heb je VBA voor nodig. Als je het wil doen zonder programmatie kan je parameter queries gebruiken.
Dat wil zeggen dat je in de design weergave van de query in de criteria-lijnen de naam van de formuliervelden invoert:

bv:

Volgens mij kun je een query met parameters niet exporteren, maar ik kan me vergissen natuurlijk. Sowieso moet je oppassen met datums, omdat die geconverteerd moeten worden naar Amerikaanse notatie. De veiligste manier is om de query te voorzien van ‘vaste’ criteria die je vanuit je formulier in de SQL van je query zet. Dat kan alleen met VBA, maar dat is dus de veiligste methode. Ik gebruik geen andere meer.
Als je een voorbeeldje post, kan ik dat wel voor je in je formulier zetten, want het is (als je een beetje kan programmeren) vrij simpel te maken. Ik raad je in ieder geval aan om alle andere methodes te vergeten.

als je de query parameters definieert in het parametervenster zou de export moeten lukken.

Maar het blijft niet slim om te doen.

Correctie: het is volgens Octafish niet slim om te doen, iedereen heeft zijn eigen werkwijze, en voor elke werkwijze zijn voor- en nadelen aan te geven

Het lijkt mij nou juist zo leuk als je in een forum de beste oplossing geeft, zeker voor mensen die net beginnen. Wat moeten die nu met oplossingen waar alleen maar nadelen aan zitten? Ik ben blij dat mijn rijinstructeur niet is begonnen met mij uit te leggen hoe autorijden niet moet....

De beste oplossing voor mij is niet altijd de beste oplossing voor iemand anders. Ik gebruik bv. nooit Access als Backend, maar dat betekent niet dat het voor iemand anders niet de beste oplossing is. Daarom blijft het cruciaal verschillende oplossingen aan te reiken waaruit de gebruiker kan kiezen.

Voor elke vraagsteller in dit forum is Access de beste oplossing, anders zouden ze hier geen vraag stellen. En het is bepaald niet ‘cruciaal’ om meerdere oplossingen aan te reiken; het gros van de gebruikers is maar geïnteresseerd in één (bij voorkeur juiste) oplossing. Moet er niet aan denken dat ik bij alle vragen meerdere oplossingen moet gaan uitzoeken... en dat geldt uiteraard ook voor de vragensteller. Tenzij TS zélf vraagt om meerdere oplossingen, dan is het wat anders. Daar heb ik echter in dit draadje nog geen bewijs voor gezien.

...

Beiden bedankt voor jullie geboden hulp!
Bij de Parameters in de query 'wil' Access steeds persé dat ik iets handmatig in een popup invul. Terwijl het toch juist het idee is dat een gebruiker iets in een veld op een Form invult en dan niets hoeft te doen. Het leek er op alsof de query het niet ok vind als een criterium veld werd leeggelaten.

'Beste' is, zoals ik het het zie, afhankelijk van wat je kiest qua "het beste in wàt". Wat is de beste hardloper? De snelste? De hardloper met het grootste uithoudingsvermogen?
Voor mij is denk ik 'Het beste" een werkwijze waar ik zelf nog verder aan kan sleutelen. Dat ik later nog iets toe kan voegen of weglaten. Een knop die een code Macro/Command activeert waarbij die code een stuk tekst uit een veld vist en die in een criterium van een bepaalde kolom in de query plaatst.
Octafish was zo vriendelijk mij aan te bieden een code te maken
Ik post hier het Access bestand (val niet over rommelige opmaak, het is niet af) Heb namen e.d. veranderd in fantasiegegevens.

Voor de zekerheid de situatie nog eens uitgelegd:
Er is een Table met daarin records per leerling per les, ik noem het 'Basis tabel Gevolgde lessen'. Elke record heeft dingen als LesDatum, LesSoort, Cursist, AanwezigheidCursist, Docent etc etc.
Van deze Table is een query gemaakt. Alles van de tabel staat in de query.

Mijn wens is om op een formulier 2 knoppen te hebben. (zijn rood in mijn voorbeeld)
Als je op de knop 'Bekijk Lessen' klikt dan moet zich een lijst van alle lessen openen. (de query of een report van de query, weet niet wat handiger is)
Als je op de rode knop 'Exporteer Lessen naar excel' klikt, dan moet de query als excel worden opgeslagen. Deze beide dingen kan ik voor elkaar krijgen.
Maar nu mijn vraag: ik wil graag dat de gebruiker, op het Startform, dingen in de groene velden in kan vullen die als filter/criteria dienen in de query die je gaat bekijken of opslaan als excel.

Dit forum wil het bestand niet uploaden. Staat niet waarom, misschien te groot.
Downloadlink WeTransfer:
https://wetransfer.com/downloads/59cc54f82f02edb70cc463b751fa979720200801123714/9519fdbfffd92b0c3c6d7c47a8ce34ff20200801123746/d6c91e

Tip: als je access bestanden, of andere bestanden die code bevatten wil doorsturen: eerst zippen, dan lukt het meestal wel.

Zullen we eens beginnen bij de basis? Er zit namelijk nogal wat 'verkeerd' in jouw tabellenstructuur, en het lijkt mij logisch om dat eerst in orde te maken voordat je verder gaat met bouwen. Dan vergeten we dat 'geneuzel' over wat al dan niet de beste oplossing is .

Om te beginnen: je tabellen bevatten data redundantie. Dan gaat het om de tabel [Basis tabel Gevolgde lessen], waarin de velden [CursistRoepnaam], [CursistTussenvoegsel], [CursistAchternaam] en [CursistGeboortedatum] al in de tabel [Basis tabel Persoonsgegevens]. Die moeten/mogen daar dus uit. Algemene regel: gegevens die je al in een tabel hebt staan, zet je niet nog eens in andere tabellen. In het geval is het veld [CursistID] al voldoende om de relatie te leggen. Je doet hetzelfde overigens ook met docentgegevens. Haal die weg, en koppel op het veld [DocentID]. En je doet het óók in de tabel [Basis tabel Cursusovereenkomst]. Haal alle dubbele gegevens dus gelijk weg, want ze gaan alleen maar in de weg zitten.

Punt twee: je gebruikt wel heel lange namen voor velden en tabellen, met daarin veel spaties (probeer die te vermijden) en leestekens in veldnamen zoals vraagtekens. Probeer die óók te vermijden, want dat zijn programmaspecifieke tekens, en je zou daar problemen mee kunnen krijgen. Het is ook niet nodig; als je een 'verklarende tekst' bij je velden wilt, typ die dan in de eigenschap Bijschrift. Dan zie je díe tekst i.p.v. de veldnamen. Het programma gebruikt dan 'veilige' namen, en de gebruiker zíet de logische tekst.

Punt 3: Je hebt zoveel mogelijk gegevens in één tabel gestopt, vooral in de tabel tblPersoonsgegevens (zelfde naam, veel handiger ). Sla in de tabel Persoonsgegevens alleen ook persoonsgegevens op, en geen andere gegevens. Lang niet alle vragen zijn van toepassing op alle personen, en het kan dus wellicht zinvol te zijn om een scheiding te maken in onderwerpen die je in de tabel opslaat.

Punt 4: Van een veld als [Gealfabeticeerd in Latijns schrift] heb je een tekstveld gemaakt (nota bene met een lengte van 255 tekens) waar je niet eens een tabel achter hebt gehangen, maar een query op een tabel. Erg onhandig, zeker als je bedenkt dat je maar twee mogelijkheden hebt: Ja en Nee. Gebruik dan een Ja/Nee veld, en geen keuzelijst. Of heb je een hekel aan je gebruikers? Wat die veldlengte betreft: je gebruikt overal 255 tekens, ongeacht de inhoud. Is niet handig, want als je een formulier maakt van een tabel gebruikt Access de veldlengte om zelf maar vast wat groottes voor je velden in te stellen. Hou je de veldlengte kleiner, dan beperk je de mogelijkheid dat er onzin in wordt getypt in die velden. Een veld als Postcode is met 10 tekens lang genoeg. Technisch maakt het niet zoveel uit, maar je db wordt er netter van.

Visara zei:

Als je op de knop 'Bekijk Lessen' klikt dan moet zich een lijst van alle lessen openen. (de query of een report van de query, weet niet wat handiger is)

Klik om te vergroten...

Ik zou zeggen: Formulier of rapport. Maar nooit query. Gebruikers hebben niks te zoeken in tabellen of queries; de complete GUI (gebruikersinterface) maak je m.b.v. formulieren en rapporten. De rest maak je straks onzichtbaar. Gebruikers met te weinig kennis kunnen simpelweg teveel kapot maken.

Ik zal alvast een voorzetje maken voor je knop (de filter variatie). Voor de standaard export heb je namelijk niks nodig, dat zit al standaard in Access. Je kunt namelijk zonder iets te maken al een tabel of query exporteren. Als je de knop weet te vinden . Bovendien heeft Access daar standaard knoppen voor, die een ingebouwde macro gebruiken.

Dag Visara,

ik heb je database bekeken, en omdat je structuur niet echt compatibel is met een relationeel ontwerp heb ik een eenvoudige query qryNGA_test gemaakt die de datum gegevens ophaalt uit jou basistabel Cursusovereenkomst. Ik heb je startformulier aangepast zodat je een datum kan kiezen in de vakjes datum van t/m. Als je op de knop test NGA klikt dan wordt een excel opgeslagen in de folder die je in de click-event van de knop opgeeft (in mijn voorbeeld is dat de D:> schijf omdat dit op mijn systeem de data schijf is, dat moet je aanpassen in de code voor jou systeem. Dit geeft een voorbeeld hoe een parameter query kan werken voor export.
Aangezien jou database niet echt conform is met een relationeel database design zou ik, voor je nog veel tijd in programmatie steekt, eerst nog eens een analyse doen: wat heb ik als gegevens en wat is mijn doel: rapportage, bijhouden van gegevens. Hou ook degelijk rekening met GDPR - privacy regelgeving.

Ik heb een paar van mijn aanwijzingen verwerkt in je startformulier, waaronder aanpassen van de tabelnamen, en het verwijderen van de overtollige velden. Tevens een tabel Docent aangemaakt, want die had je dus niet. Het filteren op datum kun je met een Datepicker doen op tekstvelden, dus ik heb je labels (die verder niks doen) omgezet naar tekstvelden waarin je dus een datum kunt kiezen. Bij het kiezen van datums is het essentieel dat de Einddatum altijd ná de Begindatum ligt, dus daar zit een check op. Beide rode knoppen maken gebruik van dezelfde query, zul je wel zien, en dat is ook logisch omdat ze min of meer op dezelfde gegevensbron werken. M.b.v. de code wordt steeds de SQL van die query veranderd en opgeslagen, en ik vind dat dus de veiligste manier van werken.

Je hebt een (in mijn ogen) hele vreemde tabel gemaakt voor de Tussenvoegsels. In mijn jaren als trainer gebruikte ik zo'n tabel als voorbeeld van hoe je te ver door kunt slaan met normaliseren van een database . Tekstvelden, zoals naamvelden, baseer je in beginsel nooit op een tabel, en een tussenvoegsel is nou typisch zo'n voorbeeld waarmee je teveel doet. De meeste tussenvoegsels bestaan maar uit een paar letters, en iedere gebruiker typt die gewoon in met het toetsenbord. Dat is veruit de snelste methode; een keuzelijst moeten openen om doorheen te scrollen om een tussenvoegsel kost gewoon veel te veel tijd. Je wint er dus gewoon helemaal niks mee. Als je dit soort gegevens al wilt 'normaliseren', dan is het eind zoek, lijkt mij. Want dan moet je Achternamen óók gaan opslaan in een tabel .

Ik heb in mijn hele carrière in de automatisering maar één keer een tabel gebruikt voor tussenvoegsels, en dat was dan omdat er vanuit een import maar één veld was voor de volledige naam, en ik moest dus op basis van tussenvoegsels de voornamen scheiden van de achternamen. Maar dan heb je het dus over eenmalig gebruik van zo'n tabel. En daar zie ik hier geen noodzaak voor. Omzetten dus naar een gewoon tekstveld, net als al die Ja/Nee velden gewoon terug kunnen naar een gewoon tekstveld met de eigenschap Ja/Nee.

Zoals gezegd: je hebt nog een hoop werk te doen aan de ontwerpkant; doe dat eerst voordat je teveel tijd steekt in de cosmetische aanpassingen. Want die moet je anders straks allemaal overnieuw doen. Eerst zorgen dat de basis in orde is!

Lieve NoellaG en Octafish,

Wederom mijn dank voor jullie assistentie in mijn eerste stappen met dit programma. Het is echt een mooi programma trouwens
Leuk dat jullie je kennis willen delen.

(...)eerst nog eens een analyse doen: wat heb ik als gegevens en wat is mijn doel: rapportage, bijhouden van gegevens (...)

Klik om te vergroten...

Het doel is een database-bestand voor een prachtig startend bedrijfje. Opgericht door lieve vakmensen met het hart op de juiste plek. Behalve dat ik hen graag help, is het voor mij een manier om ervaring op te doen met een tot voorheen voor mij onbekend programma.
De wensen van de toekomstige gebruikers:
Een Database-bestand waar ze alle NAW gegevens op kunnen slaan.
Ingevulde Intake-formulieren kunnen invoeren.
Docenten willen hun papieren lesformulieren in kunnen (laten) voeren, de Presentielijst in het Access-bestand. De ingevoerde data in tblLessenGevolgd kan worden gebruikt om overzichten op te roepen in het scherm of specifieke delen na filtering exporteren naar excel.
Hun standaard cursusovereenkomst (contract) is een Word-bestand. Met behulp van Verzendlijsten-functie in Word kan er soepel een contract in Word worden gemaakt met de gegevens uit tblCursusovereenkomst.
Verder wordt tblCursusovereenkomst gebruikt voor een overzicht waarin de gebruiker kan zien welke cursusovereenkomsten bijna of net zijn verlopen (Rapport 'Cursusovereenkomsten einddatum')

Ik kreeg het advies gegevens niet dubbel op te slaan, zoals bijvoorbeeld een Roepnaam in zowel tblPersoonsgegevens én tblCursusovereenkomst.
Dan moeten bij het Rapport 'Cursusovereenkomsten einddatum' en bij de Verzendlijsten in Word (Cursusovereenkomst Word-bestand) dus gegevens direct uit meerdere tabellen worden gehaald of in plaats daarvan uit een query die de gegevens uit meerdere tabellen haalt, toch? Wordt meer gedoe. Het bestand wordt dan wel kleiner (zal niet veel zijn in deze context, minder dan 1 MB lijkt me).
Zoals het nu is kan de Roepnaam bijv alleen worden aangepast in tblPersoonsgegevens. Als dat wordt gedaan veranderd deze Roepnaam nu niet mee in de cursusovereenkomst records. Dat realiseerde ik me en ik voorzie geen probleem. Als een persoon zijn naam verandert of verhuisd hoeven tekstvelden in records van opgestelde cursusovereenkomsten niet mee te veranderen, zoals ik het zie. Er is zelfs iets voor te zeggen om niet eens te wíllen dat het mee veranderd. Als ik in een archief duik om een oude cursusovereenkomst op te zoeken moeten/hoeven de toen ingevoerde gegevens niet zijn veranderd, denk ik. Ik wil natuurlijk wel de persoon kunnen vinden, daar is de ID voor.
De records in 'tblCursusovereenkomst' lijken mij geen dynamische records te hoeven zijn die mee moeten veranderen bij een verhuizing van een cursist (adres wijziging in tblPersoonsgegevens). Zo'n record in cursusovereenkomsten is er voor om kort na de invoer de Verzendlijsten in Word te vullen en om in een overzicht te staan met andere cursusovereenkomsten om te zien of er eentje al bijna verlopen is.
Is het advies, na deze informatie, nog steeds om dingen als namen niet een extra keer op te slaan in cursusovereenkomst? Blijft het advies overeind zodat onvoorziene toekomstige toevoegingen in dit bestand geen problemen gaan geven en het bestand kleiner te maken/houden? Is er nog iets anders dat ik door mijn gebrek aan kennis niet zie?

In de Tabel 'tblLessengevolgd' ga ik sowieso stoppen met dingen als Achternamen invoeren. Ik zal het houden bij ID's, en zo de tblLessenGevolgd zo clean en klein mogelijk houden. In die tabel gaan veel records terecht komen.
Ik zou wel willen dat de gebruiker meer dan alleen de ID ziet na het selecteren van een persoon dmv een combobox in Form Presentielijst. Dus de naam etc moet niet alleen maar tijdens het openen van de combobox te zien zijn. Na het selecteren van een persoon hoeft alleen de ID van die persoon te worden ingevuld in tblLessenGevolgd, maar in het formulier wil ik de Roepnaam, Achternaam, Geboortedatum etc zichtbaar hebben (ja, ook geboortedatum. De helft van de cursisten heeft een Arabische naam, de variatie in namen in die taal is vrij klein. Geboortedatum helpt gebruikers de kans op vergissingen te verkleinen).

Ik zal alvast een voorzetje maken voor je knop (de filter variatie). Voor de standaard export heb je namelijk niks nodig, dat zit al standaard in Access.

Klik om te vergroten...

De standaard export doen dmv een knop kan ik en zit al in het bestand, het ging me inderdaad om een ingebouwde Filter-functie.
Bedankt voor de opzet!
Is het je bedoeling dat het filteren al werkt? Want dat doen ze niet. Als ik de code lees zie ik natuurlijk dat er naar tabellen en kolommen er wordt verwezen en kan ik half raden wat en waarom dingen er staan zoals ze staan.
Afhankelijk van welke filter ik invul gaat er iets mis met met de code, zie bijlage. Het gele vlak of het geel omkaderde stuk gaan mis. Je hebt een query1 gemaakt in het bestand die voor mij hetzelfde lijkt te zijn als een al bestaande query, 'qGevolgdeLessen', maar jouw code maakt alleen gebruik van mijn 'oude' query qGevolgdeLessen? De functie van 'query1' ontgaat me.
De knop BekijkLessen die het form opent om de lessen te bekijken filtert ook niet.
Het bekijken van de Lessen kan doordat de knop BekijkLessen een form opent, bedankt voor het maken van de form. Maar er vindt geen filter plaats.
Is dit zoals het de bedoeling is, ik ga eerst de basis netjes maken? Ik zie wel 'Filter' in de code staan.
Leuk dat je een check hebt ingebouwd die bekijkt of de 't/m datum' voorbij de 'tot datum' ligt

Octafish gaf aan dat ik geen tabel heb voor Docenten. Dat klopt, ik heb een tabel met Persoonsgegevens, het is/was mijn bedoeling daar ieder mens onder te brengen. Ik zie geen aanleiding om Docenten in een andere tabel onder te brengen. Ik heb een query gemaakt die alle ZZP'ers en Medewerkers uit de Persoonsgegevens filtert. Dit zijn alle docenten. Niet handig gekozen van mij, want in de toekomst zijn misschien niet alle medewerkers een docent. 'Docent' moet toegevoegd worden als relatietype en daar moet ik dan een query voor maken.
Octafish gaf als 'punt 3' de suggestie een tabel Persoonsgegevens te maken en een aparte tabel met dingen die alleen voor de cursisten van toepassing zijn (groot deel van Intakeformulier).
Maar waarom zou ik dan een aparte tabel voor de docenten maken?
Zal ik in tblPersoonsgegevens alle mensen onderbrengen met basis dingen als NAW en een Relatietype? (Docent, Cursist, Vrijwilliger etc) En dat ik de dingen die nu in Persoonsgegevens staan en alleen Cursisten aangaan in een aparte tabel? (Intake dus)

Ik heb in mijn hele carrière in de automatisering maar één keer een tabel gebruikt voor tussenvoegsels

Klik om te vergroten...

Ja, is een beetje too much hè Ik vond het deels grappig vanwege alle obscure tussenvoegsels die blijken te bestaan en deed het ook een beetje om de gebruiker te attenderen op de verschillende schrijfwijzes. Voorbeeld: zowel 'El' als 'el' bestaan. En aangezien sommige gegevens met gemeentes en overheden moeten worden gedeeld kan je je daar geen fout in permitteren. Maar of je er als gebruiker er echt blij van wordt... Ik zal het weghalen

Hou ook degelijk rekening met GDPR - privacy regelgeving.

Klik om te vergroten...

Ja, dat is een goed punt. Dank.

mvg, Visara

Visara zei:

Dan moeten bij het Rapport 'Cursusovereenkomsten einddatum' en bij de Verzendlijsten in Word .. dus gegevens direct uit meerdere tabellen worden gehaald of in plaats daarvan uit een query die de gegevens uit meerdere tabellen haalt, toch? Wordt meer gedoe. .. Er is zelfs iets voor te zeggen om niet eens te wíllen dat het mee veranderd. .. Is het advies, na deze informatie, nog steeds om dingen als namen niet een extra keer op te slaan in cursusovereenkomst?

Klik om te vergroten...

Onveranderd: JA . Het gaat uiteraard niet om de grootte van de database (al is elk grammetje er één), maar het is om meerdere redenen een principekwestie: voorkomen van dataredundantie is één van de grondbeginselen van een goede database. Als je je gaat verdiepen in de materie, dan zal je dat hopelijk wel duidelijk worden. Ik maak me dus een beetje zorgen om de tekst die ik in de quote heb gemarkeerd: "wordt meer gedoe". Dat is een verkeerd uitgangspunt; 'gedoe' mag nooit een reden zijn om iets wél of níet te bouwen in de database. Betrouwbaarheid, Degelijkheid en Data-integriteit moet te allen tijde voorop staan bij het ontwerp. Voorkomen van 'gedoe' valt daar niet onder .
Bovendien lijkt het mij vele malen meer 'gedoe' als je voor elke persoon dezelfde gegevens steeds twee keer moet invoeren. Kost echt meer tijd dan één keer een query maken (voor je export, rapporten, Mailmerges etc) die je dan steeds hergebruikt.

Visara zei:

Als ik in een archief duik om een oude cursusovereenkomst op te zoeken moeten/hoeven de toen ingevoerde gegevens niet zijn veranderd. .. De records in 'tblCursusovereenkomst' lijken mij geen dynamische records te hoeven zijn die mee moeten veranderen bij een verhuizing van een cursist (adres wijziging in tblPersoonsgegevens). Zo'n record in cursusovereenkomsten is er voor om kort na de invoer de Verzendlijsten in Word te vullen en om in een overzicht te staan met andere cursusovereenkomsten om te zien of er eentje al bijna verlopen is.

Klik om te vergroten...

Daarnaast is het nog maar de vraag of je überhaupt als bedrijf het recht hebt om persoonsgegevens in deze hoeveelheden a) te vragen, b) op te slaan en c) te bewaren vanuit historisch oogpunt. Het opvragen/bewaren van BSN nummers bijvoorbeeld is (terecht) aan strenge regels gebonden. Zo mag je een identiteitsbewijs wel zien om te controleren of de persoon voor je is die hij/zij zegt te zijn, maar je mag er geen kopie van opslaan. Dus óók geen BSN nummer. En zo kan ik nog wel even doorgaan .

Visara zei:

Ik zou wel willen dat de gebruiker meer dan alleen de ID ziet na het selecteren van een persoon dmv een combobox in Form Presentielijst. Dus de naam etc moet niet alleen maar tijdens het openen van de combobox te zien zijn.

Klik om te vergroten...

Dat is in een formulier m.b.v. een Keuzelijst (met invoervak) simpel te maken. Sterker nog: op mijn formulier staat al een keuzelijst waarin exact die constructie al gebruikt wordt. Je neemt dus de extra gegevens die je wilt zien in je keuzelijst mee in de query die je gebruikt voor die keuzelijst. De keuzelijst slaat het ID nummer op, maar toont dus verder alles wat je nodig hebt om te kunnen selecteren.

Visara zei:

Is het je bedoeling dat het filteren al werkt? Want dat doen ze niet. Als ik de code lees zie ik natuurlijk dat er naar tabellen en kolommen er wordt verwezen en kan ik half raden wat en waarom dingen er staan zoals ze staan. Afhankelijk van welke filter ik invul gaat er iets mis met met de code, zie bijlage. Het gele vlak of het geel omkaderde stuk gaan mis. Je hebt een query1 gemaakt in het bestand die voor mij hetzelfde lijkt te zijn als een al bestaande query, 'qGevolgdeLessen', maar jouw code maakt alleen gebruik van mijn 'oude' query qGevolgdeLessen? De functie van 'query1' ontgaat me.

Klik om te vergroten...

Ik heb vermoedelijk dan andere combinaties getest als jij, want ik ben geen fout tegen gekomen. Maar goed, het was al laat toen ik 'm maakte . In de code zie je een regel tmp = Inputbux. Die is groen, want gemarkeerd als commentaar. Je kunt die twee '' tijdelijk weghalen. Als je de knop dan uitvoert, komt hij met een Inputbox met daarin de gegenereerde SQL. Die kun je kopiëren (<Ctrl>+<c> en dan, als de code weer vastloopt en je hebt beëindigd, in een nieuwe query plakken die je maakt zonder dat je tabellen kiest. Access komt dan met een SQL venster met de tekst SELECT;. Die tekst haal je weg en vervang je door de code die je zojuist hebt gekopieerd (<Ctrl>+<v>). Je kunt dan proberen de query uit te voeren. Als er inderdaad een fout in zit, kom je niet heel ver, maar vermoedelijk kun je de fout wél terugvinden op deze manier. Zo is query1 ook ontstaan; ik heb dus één van de testversies opgeslagen voor later gebruik, mocht ik dat nodig hebben. Hij heeft verder inderdaad geen functie.

Visara zei:

De knop BekijkLessen die het form opent om de lessen te bekijken filtert ook niet.

Klik om te vergroten...

Dat klopt; daar heb je in bericht #11 ook om gevraagd

Visara zei:

Van deze Table is een query gemaakt. Alles van de tabel staat in de query. .. Als je op de knop 'Bekijk Lessen' klikt dan moet zich een lijst van alle lessen openen.

Klik om te vergroten...

Je kunt de filtertechniek die voor de andere knop is gebruikt uiteraard makkelijk overzetten naar andere knoppen.

Visara zei:

.. ik heb een tabel met Persoonsgegevens, het is/was mijn bedoeling daar ieder mens onder te brengen. Ik zie geen aanleiding om Docenten in een andere tabel onder te brengen.

Klik om te vergroten...

Die is er dus wel degelijk! Om te beginnen: je slaat nu in de tabel Persoonsgegevens data op die voor docenten totaal niet relevant is. Daarnaast heb je met docenten een totaal andere binding dan met cursisten. Al was het maar een dienstcontract, en een stukje salarisadministratie. Het is prima om de pure persoonsgegevens in één tabel te houden (met een extra veld TypePersoon bijvoorbeeld waarin je aangeeft wat de status is van die persoon (docent, cursist, administratie etc). Maar dan moet je dus de niet-gebonden NAW gegevens verplaatsen naar andere tabellen. Eigenlijk precies zoals ik al in een eerder antwoord aangaf.

Visara zei:

Octafish gaf als 'punt 3' de suggestie een tabel Persoonsgegevens te maken en een aparte tabel met dingen die alleen voor de cursisten van toepassing zijn (groot deel van Intakeformulier). Maar waarom zou ik dan een aparte tabel voor de docenten maken?
Zal ik in tblPersoonsgegevens alle mensen onderbrengen met basis dingen als NAW en een Relatietype? (Docent, Cursist, Vrijwilliger etc) En dat ik de dingen die nu in Persoonsgegevens staan en alleen Cursisten aangaan in een aparte tabel? (Intake dus)

Klik om te vergroten...

Ja dus.

Dat is dus de 'straf' als je lange epistels schrijft: je krijgt er een net zo lange voor terug .

Dat ervaar ik niet als straf, maar als extra les

als je voor elke persoon dezelfde gegevens steeds twee keer moet invoeren

Klik om te vergroten...

Dat doet een Combobox met autopopulate voor de gebruiker. Behalve het selecteren van de cursist vanuit een Combobox hoeft de gebruiker nergens iets dubbel in te voeren.
Het punt van redundantie is me inmiddels duidelijk, dank.

BSN nummers opslaan

Klik om te vergroten...

Om facturen aan te leveren aan de overheidsinstelling die gaat over deze materie moet de BSN-nummer in de aangeleverde exceltabel staan, het aangeleverde bestand wordt zelfs automatisch geweigerd als het ontbreekt.
Ik zal hen wijzen op de rare spagaat met 'verplicht elke keer aanleveren' & 'mag niet opslaan'.

op mijn formulier staat al een keuzelijst waarin exact die constructie al gebruikt wordt

Klik om te vergroten...

Ah! Die zag ik natuurlijk, maar ik realiseerde me niet dat die met de ID werkt (omdat ik die niet in het combobox-veld zag staan). Ook voor mij was het laat. Tof, heb ik gelijk een mooi voorbeeld

Ik ga er mee aan de gang, bedankt voor je moeite!

Graag gedaan . Ook voor de overheid zijn de AVG regels zo helder als erwtensoep, vrees ik. Maar als je moet uitwisselen met (lokale) overheden, val je wellicht onder de uitzonderingsregels. Al is het zeker de moeite waard om dat goed uit te zoeken, ook in verband met de bewaartermijn waarin je gegevens mag bewaren.