Kleur aan vogel koppelen nog neit gelukt

Hallo,
De vraag heb ik eerder gesteld.
Ik heb nu alle keuze lijsten uit de tabel Vogels_2017 gesloopt zoals je terecht opmerkte.
Nu heb ik een query gemaakt test 2018, waar ik de vier volgende velden wil zien.
Ringnummer - Kleur - Splitkleur (indien aanwezig) - geslacht.
Van het veld Ringnummer heb ik wel in de query een keuzelijst gemaakt, dit is makkelijk want dan hoef ik vaak niet het gehele ringnummer in te voeren.
Van de query heb ik een formulier gemaakt.
Nu is het de bedoeling dat als ik bij het ringnummer 9RCH-03-2015 tik dat de kleur Zwart geel Intensief word, en het geslacht MAN.
Splitkleur is bij deze niet van toepassing.

Maar helaas, ik zie waarschijnlijk iets heel simpels over het hoofd, het lukt niet.

Bijgevoegd een uitgeklede database, met alleen Tabel, Query en formulier

elluko zei:

Van het veld Ringnummer heb ik wel in de query een keuzelijst gemaakt, dit is makkelijk want dan hoef ik vaak niet het gehele ringnummer in te voeren.
Van de query heb ik een formulier gemaakt.

Klik om te vergroten...

En dat zeg ik dus steeds: keuzelijsten horen op formulieren thuis, niet in tabellen en queries. Als je een formulier hebt, dan doe je daar toch je mutaties in? Je gaat toch niet in een tabel of query lopen klooien? Ik doe mijn boodschappen ook met de auto, maar ik duw die auto daarna nooit naar huis .
Ik zal eens bekijken wat je over het hoofd ziet!

Je ziet inderdaad iets simpels over het hoofd, en wel het het simpele feit dat je van het veld [Ringnummer] nooit een keuzelijst had mogen maken. En al helemaal niet in de query, waar hij totaal zinloos is. Je bent nu in de (verkeerde) veronderstelling dat je m.b.v. die keuzelijst een andere vogel kunt opzoeken. Maar dat is dus niet zo: je bent met die keuzelijst een bestaand record aan het muteren. Anders gezegd: als je in het eerste record (in je formulier of query) "9RCH-03-2015" intypt, verander je vogel "061-12-79-31" met de kleur "Zwartonyx wit" in "9RCH-03-2015". Uiteraard houdt die 'nieuwe' vogel de kleur die hij al had, tenzij je die dan in het record verandert naar "Zwart geel intensief". Maar dat mag natuurlijk nooit gebeuren, lijkt mij.

Kortom: niet doen op deze manier! Keuzelijsten die gegevens uit een formulier halen, zoals een keuzelijst waarmee je een vogel selecteert, gebruik je nooit op de eigen tabel, maar alleen op gekoppelde tabellen. Dus als je een broedtabel hebt, waarin je een vogelpaar samenzet, dan gebruik je op die broedtabel 2 keuzelijsten waarmee je vogels selecteert uit de tabel [Vogels_2017]. De één met een selectie op Man, en de ander met een selectie op Vrouw.
Wat je in het formulier Test2018 wél kunt doen, is een keuzelijst maken waarmee je een vogel opzoekt. Die keuzelijst is dan niet-afhankelijk en zet je bij voorkeur in de koptekst van je formulier.

Ik snap er neits van

beste,

Geloof dat ik het niet echt snap.
Ik ga nooit muteren in de tabel en/of query.
Heb in de query het keuzeveld weer veranderd naar een tekstvak.
Wat eerst niet ging hou ik nu in mijn formulier wel de mogelijkheid van een keuzelijst.

Wat ik probeer te bereiken is om in het formulier bijvoorbeeld:

Voor de vogel 9RCH-103-2016 in te tikken, het ringnummer staat er sneller door de keuzelijst.
Want er zijn veel 9RCH tjes want dat is mijn kweeknummer.

Ik verwacht niets meer van het formulier dat hij dan direct automatisch de gegevens invult van:

de kleur - in dit geval Zwart geelivoor intensief
Splitkleur - in dit geval Eumo/Kobalt
En het geslacht - in dit geval POP

Dat moet toch kunnen.
Zit nu vaak gegevens die al in de tabel 'vogels_2017' bekend zijn opnieuw in te voeren.
Veel werk en fout gevoelig.

Ik stuur de bijgewerkte testversie hier mee.

elluko zei:

Geloof dat ik het niet echt snap.
1. Ik ga nooit muteren in de tabel en/of query.
2. Heb in de query het keuzeveld weer veranderd naar een tekstvak.
3. Wat eerst niet ging hou ik nu in mijn formulier wel de mogelijkheid van een keuzelijst.

Klik om te vergroten...

Ik heb er maar even wat punten van gemaakt, dat praat makkelijker.
Ad 1: Dat maakt niet uit, maar des te meer reden om geen keuzelijsten te gebruiken. Bedenk goed dat een formulier is gebaseerd op een tabel en alles dat je doet werkt door in de tabel.
Ad 2. Dat helpt niets bij je probleem; is overigens veel beter om altijd tekstvelden in tabellen en queries te gebruiken, zoals ik al heb uitgelegd.
Ad 3. Een formulier is een zelfstandig object, dat je kunt baseren op een ander object zoals een tabel of query. Als je daar een formulier van maakt, erft het formulier alle objecteigenschappen van die tabel of query. Dus ook of een veld een tekstveld is of een keuzelijst. Is het formulier opgeslagen, dan heeft het in feite niets meer met het oorspronkelijke object te maken. Gooi je in de tabel een veld weg: jammer, in het formulier blijft het gewoon staan. Verander je een veld van keuzelijst naar tekstveld? Idem dito: dikke pech, want op het formulier stond al een keuzelijst, en die blijft er gewoon staan. Het is niet voor niets dat ik altijd zeg dat je formulieren pas moet maken als de tabellen klaar zijn, want je blijft anders dubbel werk doen.

Maar je moet dus goed in het achterhoofd houden dat je formulier niets anders is dan een schil die bovenop de tabel ligt, en alleen het uiterlijk van de tabel verandert. Vergelijk het met de kleren die je zelf aantrekt; het maakt niet uit wat je aan hebt, je blijft toch dezelfde persoon. En als we bij jou terwijl je netjes in het pak bent gestoken een been afzaken, dan is niet alleen het pak een been kwijt, maar jij ook. Of zoiets.
Het formulier doet dus nooit dit:

elluko zei:

Ik verwacht niets meer van het formulier dat hij dan direct automatisch de gegevens invult van:

Klik om te vergroten...

Want dat kán dat formulier helemaal niet. Als jij in je tabel 143 records heeft, heeft het formulier er ook 143. Als jij in de tabel een kleur van een vogel verandert, zie je in het formulier dezelfde kleur terug. En omgekeerd: als jij in het formulier iets verandert, verander je het dus in de tabel. Het formulier doet daar helemaal niks aan. (normaal gesproken, maar zeker in jouw formulier).
Bladeren in het formulier door de records is dus precies hetzelfde als bladeren door de tabel, of in jouw geval de (overbodige) query die je hebt gemaakt.

Wat je dus wél kan doen, is een keuzelijst in het formulier maken die een record opzoekt. Ik heb er een voor je gemaakt met de wizard; die maakt een macro aan, die ik voor het gemak maar heb laten staan. Al jeuken de vingers om die aan te passen, want dat doe ik met VBA veel netter en beter. Maar hé, het gaat om het idee .

Weer bedankt

beste,

Sorry voor de late reactie, maar het is nu de tijd om alle vogels uit te zoeken en het goede vrouwtje bij haar mannetje te plaatsen.
Zodat er over 2 weken gekweekt kan worden.
Weer bedankt voor het mee denken.
1. van keuzelijsten in de tabellen ben ik nu wel af denk ik, heb naar jouw advies geluisterd en deze in de operationele database allemaal vervangen en/of veranderd.
2. ook geen query's meer met opzoekvelden
3. duidelijk is dat wanneer ik in een formulier iets veranderd, dit natuurlijk doorwerkt in de tabellen.

Wat ik misschien niet helemaal duidelijk heb gemaakt is dat de database bestaat uit twee belangrijke tabellen:
Vogels_2017: hierin staan alle naw gegevens van de vogels, ringnummer, kleur, geslacht etc etc
De 2e tabel is Broedparen 2017: hier worden per seizoen kweek data in opgselagen, waarvan een aantal velden na het beëindigen van het broedseizoen via een kopieer query in vogel_2017 worden opgeslagen.
De gegevens die gekopieerd worden naar Vogels_2017 zijn alleen de elementaire gegevens, ringnummer nieuwe jong - vader - moeder etc.
Wanneer dit gedaan is wordt de tabel broedparen-2017 niet meer gebruikt.

Nu dacht ik dat de elementaire gegevens van het broedpaar vanuit vogels_2017 direct ingelezen konden worden in broedparen 2017.
Dus alleen man - kleur - splitkleur man en pop - kleur -splitkleur pop

Via jou test db lukt dit wel in een keuzelijst die een record op zoekt.
Dit bedoel ik precies.
het zo alleen zo mooi en makkelijk zijn als hij deze gegevens direct in de tabel broedparen 2017 kwakt.

Maar misschien vraag ik het onmogelijke hoor.


Stuur voor de duidelijkheid jouw test db terug, met als toevoeging de tabel broedparen-2017 erbij

En wat niet kan kan niet hoor.

Dus even voor het begrip: je hebt een tabel Vogels (ik zou het jaartal dumpen, anders heb je volgend jaar een probleem) en een tabel waarin je de broedresultaten vastlegt. Vogels die uit een broedsel voortkomen wil je vastgelegd hebben in de tabel Vogels, want dat zijn de volgende keer ook weer bruikbare vaders/moeders. Tot zover duidelijk. Dan gaan we eens kijken naar je tabel [Broedparen-2017] want die is niet best genormaliseerd. Zodra ik velden als [Ringnummer jong 1] .. [Ringnummer jong 8] zie, weet ik dat er werk aan de winkel is. De broedgegevens zijn redelijk uniek; elke broed heeft zijn vader, moeder, datum etc. De hoeveelheid eieren, en dus ook het aantal jongen, varieert. En daar moet je dus een aparte tabel voor gebruiken met een verwijzing naar het sleutelveld ([ID] in dit geval). Daarbij kun je voor elk jong apart de eigenschappen vastleggen, als je dat wilt. Want elk jong is weer anders, neem ik aan. Al was het maar omdat je nooit kunt broeden op alleen man of alleen vrouw. Toch?

Wat je dus wilt, is de nieuwe vogels toevoegen met alle bekende gegevens van de jongen. Dat zou, als ik de db zou maken, nog wel wat aanpassingen in de tabel [Vogels] tot gevolg hebben, want als ik een vogel zou beschrijven in een tabel, dan wil ik weten wanneer die geboren is, welk geslacht de vogel is, welke kleur die heeft, welke vogel de vader is en welke de moeder. En eventueel details en waar de vogel gekocht is, als het geen eigen kweek is. Maar de kleur van de vader of moeder? No way..... De vader staat immers óók al in de tabel, en dáár is de kleur al vastgelegd. Idem voor de moeder. Jij doet op deze manier aan een enorme berg dataredundantie, waarbij je één en dezelfde vogel bij de ene broeD pimpelpaars kan maken, en de volgende keer lichtgroen met een blauwe bies. Niemand die je tegenhoudt....

Kweekgegevens

Ringnummer van de jongen 1 t/m 8 leek mij makkelijk omdat er in een nest soms 5 jongen liggen met dan natuurlijk dezelfde ouders.
Ik hoef dan niet steeds voor ieder jong de ouders weer in te vullen.
En als ik pimpelpaarsen of vogels met een blauwe bies zou kunnen kweken stop ik pre direct met werken.
want die zijn geld waard.

Ik zal de vraag verder afsluiten.

De grap is: je hóeft de ouders natuurlijk niet steeds dubbel in te voeren, want als je een subformulier gebruikt onder de broeinesten tabel (en dat doe je natuurlijk) dan koppel je die op basis van zowel vader als moeder. En dat wordt dan automatisch ingevuld. Ja, zeg niet dat Access niet slimmers .