Resultaten van Ja/nee veld in form1 als criteria voor query op basis v form2

Ik maak een database voor planten en wil het volgende kunnen filteren: "Welke planten zijn geschikt voor het bodemtype en de bezonning van de klant.
Ik heb een formulier om klantinfo in te vullen, met een subformulier voor de verschillende bodemeigenschappen en bezonningen die bij die klant terugkomen ahv wisselknoppen (dus ja/nee)
Ik heb een formulier om plantfiches te maken waar de bodemeigenschappen en bezonning ook per plant ahv wisselknoppen worden ingevuld.
Ik heb bij de klant een printknop die dan de geselecteerde rapporten afdrukt. Die knop gebruikt een query waarbij de bodem- en zon-eigenschappen van de klant als criterium dienen voor de plantfiches.
Het werkt maar ik heb het probleem dat ik alleen de ja's als criterium wil gebruiken en niet de nee's. Nu worden bvb enkel planten getoond die alleen op zand groeien en niet op zandleem. Ik wil echter alle planten zien die op zand groeien, ook als deze ook op zandleem, klei... groeien.
Is dit mogelijk? Dus zeggen dat hij de info van het formulier enkel als criterium moet gebruiken indien het een ja is?
Heb nu:


Ik ben nieuw in access (zoals je mss werkt) heb via youtube al heel wat kunnen verwezenlijken, maar hier zit ik vast.
Indien mijn vraag onvoldoende duidelijk is, laat het zeker weten.
Bedankt!

Welkom bij HelpMij! Alleen een plaatje is niet genoeg, vrees ik, want ik snap je vraag niet. Wel krijg ik het idee dat je de db verkeerd hebt opgezet. Maar zonder de db te zien is er dus eigenlijk niks van te zeggen.

Ik heb een gecomprimeerde map gemaakt maar wanneer ik deze oplaad (ik zie het lopen tot 100%) dan verschijnt deze niet in het vak waaruit je dan kan invoegen.
Te zwaar? 38MB gecomprimeerd (anders 44MB)
Ik weet niet of dit een normale bestandsgrootte is voor access. Er zitten maar enkele foto's echt in en deze zijn slechts een paar kb groot...

Ik had al een weddenschap lopen: zou je de QUOTE knop gebruiken om te antwoorden, of de (veel mooiere, duidelijkere en grotere) knop <Reageer op bericht>? Jammer genoeg wil niemand die weddenschap meer aan, want blijkbaar is het niet uit te roeien, en MOET elke nieuwe gebruiker de eerste keer op de QUOTE knop drukken. Maar daar is-ie dus niet voor, en graag ook niet meer doen maar de officiële antwoordknop gebruiken.

38 Mb is idioot groot voor een gecomprimeerde database, 44 Mb vind ik ook al stevig aan de maat trouwens. Mijn productiedatabases komen zelden boven de 20 Mb uit. En daar wordt fors in gewerkt. Als ik die dan comprimeer, en zip, krijg ik 'm ver onder de 10 MB. Overigens is dat ook te groot om te posten, want de grens ligt op 2Mb.
Strip alle overbodige spullen er uit (er zitten toch geen velden in met ingesloten objecten?) en laat in de tabellen een paar records staan; genoeg om de vraag te bekijken. Comprimeer de db dan nog een keer, en zip 'm. Dat zou moeten werken.
Alternatief: zet 'm op een fileshare, en post de link daarheen.

Owkay
Ik gebruikte eerst de reageer knop maar dacht dat jij dan geen melding ging krijgen van mijn antwoord. Heb het bericht dan maar gewist en via quote gewerkt ;-)
Ik heb geen idee waarom de file zo groot is er zitten amper records in en de enige ingesloten objecten zijn maar een paar kb groot.
Hierbij de link.
https://humus.sharefile.com/d-s28639453b0a43b28


alvast bedankt.

Ok ik kijk er zo even naar. Mensen krijgen pas een melding over een vraag als ze daar een bericht in posten, anders niet. Daar doet de Quote knop niets mee. De tool kijkt dus puur of je een bericht hebt op een vraag.

En? Heb je al iets kunnen opmaken uit mijn brouwsel?

Ik ben er mee bezig. De grootte heb ik overigens terug kunnen brengen tot de helft; ik snap nog niet helemaal waar de rest van de grootte vandaan komt, maar al die eigen knoppen die je gebruikt, zouden best wel eens heel veel grootte weg kunnen snoepen; Access zet die intern allemaal apart weg als bitmaps, en dat gaat dus heel hard.

Alvast heel erg bedankt! Dat gaat dan toch niet zwaarder worden per plantfiche hoop ik want dan gaat het niet te doen zijn. Of slaat hij die knoppen maar 1keer op?

Nou, dat is het punt: ik denk dat ze allemaal apart worden opgeslagen. En dan gaat het hard

:-O en dat kan niet anders? Ik ga honderden plantenfiches hebben...

Ik weet niet of dat de oorzaak is; het zijn Access knoppen dus je zou verwachten dat ze dat wel incalculeren. Ik probeer wel even wat. En het gaat natuurlijk eerst om je feitelijke vraag.

Al iets wijzer geworden? grts

Ik ben nogal druk geweest de laatste tijd, dus niet zoveel tijd gehad om naar databases te kijken. Maar dat gaat vanaf nu veranderen, dus ik kijk er wel weer naar. Er staat me iets van bij dat je wel heel veel selectievakjes hebt... en dat je dus eigenlijk een heel andere structuur nodig hebt. Maar ik kom er op terug!

Merci ! Ik kies voor ja nee om het maken van een fiche snel te laten verlopen en om het resultaat erg visueel te maken met kleur en pictogram ipv tekst dus dat wil ik liefst wel behouden. Grts

Ziet er allemaal heel mooi uit maar alle knoppen zijn ingesloten objecten (vandaar nu al de grootte van 42Mb) en ik zie in jou rapport dat de "Afbeelding58" van jouw plant ook ingesloten is. Als je dus aanhoudt straks zal je DB én traag en enorm groot worden. Die knoppen zijn mooi maar als dat voor intern gebruik is zou ik de snelheid laten primeren en daar gewone knoppen van maken. En dat rapport laten opmaken met VBA ipv een macro aan de hand van een filter of via de QueryDef je qry0PlantenlijstKruidachtigenPerKlant query aanpassen.

De rapporten zijn niet voor intern gebruik hé. Af te drukken voor de klanten.

Dat maakt toch niet uit? Een rapport moet je sowieso simpel houden qua layout, daar moet helderheid van informatie voorop staan. Johan herhaalt wat ik ook al zei: de knoppen zouden wel eens de bron van de grootte kunnen zijn. En daar ga je dus echt een keer problemen mee krijgen. Als je Db’s gaat bouwen, moet de functionaliteit voorop staan, en snelheid is daar een belangrijk onderdeel van.
Ik kan prachtige databases bouwen (om te zien) die geen meter vooruit te branden zijn door alle grafische foefjes. Zet ik daarnaast een versie zonder al die ongein, dan is die versie supersnel. Mag jij raden met welke versie de gebruiker het liefst werkt .

Je moet nooit ontwerpbeslissingen baseren op de grond ‘het ziet er mooi uit’. Eerst zorgen dat het functioneel werkt, dat de database voldoende genormaliseerd is, dat alle gegevens die je er uit wilt kunnen halen er ook daadwerkelijk uitgehaald kunnen worden. Het ‘smoel’ van een database is echt de aller-allerlaatste stap. Nou ben jij niet de eerste die begint aan de verkeerde kant; ik heb onlangs in een ander draadje ook al gezegd dat je moet beginnen met de vraag: “wat moet er uit gehaald kunnen worden”. Dat bepaalt namelijk wat je er in moet stoppen. En uiteraard hoe flexibel een database moet/mag zijn.

Simpel voorbeeldje van dat laatste: als je een klantentabel hebt en per klant een contactpersoon, dan kun je besluiten om daar een veld voor te gebruiken in de tabel. Komt er een ander, dan moet je de oude dus vervangen. Ben je de historie ook gelijk kwijt. Besluit je later dat je per bedrijf meerdere contactpersonen wilt vastleggen, dan heb je ook een probleem. Dat soort vraagstukken moet je dus van tevoren al opgelost hebben.

Zoals gezegd ben ik volledig nieuw in access, zoals je dus wel merkt
Ik ben idd omgekeerd begonnen omdat ik in de eerste plaats mooie en duidelijke fiches wil voor mijn klanten. Het is pas daarna dat ik ben gaan zoeken hoe ik dat ook makkelijk zoekbaar kan maken voor mezelf en eventueel kan koppelen aan een klant. Vandaar dus die werkwijze. Ik wil natuurlijk dat het goed werkt maar het esthetische en overzichtelijke is in dit geval dus ook wel echt belangrijk. Blijkbaar het verkeerde programma gekozen daarvoor... Begrijp niet goed dat wat knoppen met een tekening van een paar kb erop direct zo zware files generen. Dat zou access toch beter moeten kunnen ontwerpen lijkt me

JocelynH zei:

Blijkbaar het verkeerde programma gekozen daarvoor...

Klik om te vergroten...

Goede keuzes of verkeerde keuzes kun je pas vaststellen als je alles hebt gedaan wat redelijkerwijs mogelijk is. Mooi voorbeeldje van een verkeerde keuze: als je net een week je rijbewijs hebt (en hebt gelest in een Renault Clio) van je vader een Ferrari krijgen. Goede kans dat je die binnen het uur tegen een boom hebt geparkeerd. Is een Ferrari een slechte auto? Goeie vraag.... Is het in dit geval een juiste keuze? Nee. Kortom: keuzes bepaal je op grond van beschikbare kennis en vaardigheden. Microsoft vind dat elke stumper die een Word document of Excel sheet kan openen, ook een database kan bouwen. Daarbij hanteert het bedrijf één criterium: 'je kan toch een muis vasthouden?' (of, zoals in het vorige voorbeeld: 'je hebt toch een rijbewijs?').

Als je net begint met Access, is het (in mijn ogen) verplichte kost om je eerst in de onderliggende theorie te verdiepen, zodat je weet waar je bij het ontwerpen van je database rekening mee moet houden. Daarna ga je de techniek (tabellen, queries) opzetten, de data vullen en vervolgens ga je aan de interface werken. Want de nietswetende gebruiker moet feilloos met het programma kunnen werken. Dus maak je mooie formulieren en dito rapporten. Zodat de input op een vlotte en goede manier gaat, en de output er vlot en mooi uitkomt.

Opmaak heeft geen enkele invloed op de werking van je programma. Een prachtig opgemaakt rapport werkt net zo goed als het meest afzichtelijke rapporten (gebruik hiervoor vooral de Microsoft sjablonen) die je kunt maken. Dat het helpt als je een goed grafisch oog hebt, is bij het ontwerpen van formulieren en rapporten absoluut een pluspunt. Kennis hebben van het ontwerpen van een goede GUI is al helemaal fantastisch, want uiteindelijk gaat het er om dat gebruikers goed met het pakket kunnen werken. Dan maken ze ook minder fouten. Maar de interface staat dus volkomen los van het ontwerp van de database. En ik krijg nu sterk de indruk dat jij die twee door elkaar haalt.