Voorwaardelijke parameter

[EdHa]

Is het mogelijik in een parameterquery de parameter afhankelijk te maken van het vervuld zijn van een voorwaarde, zodat je meerdere criteria kunt formuleren die elk alleen maar opgaan als de voorwaarde vervuld is? Anders moet je nl meerdere van dezelfde formulieren maken met een andere query.

Voorbeeld:
Ik wil van verschillende soorten medewerkers de werkvoorraad weten. Uit de database met zaken haal ik degene die op hun naam staan. De query zoekt dus op de naam van de medewerker in de groep (tabel) Medewerkers1. Medewerkers met een andere functie vormen een andere groep (tabel), Medewerkers2, en voor die groep moet dus de parameter staan op een ander rijtje namen.

Ik werk met een keuzeformulier waar ik de naam van de medewerker laat selecteren. Dat is iemand uit Medewerkers1 of iemand uit Medewerkers2. Afhankelijk van deze keuze moet in het voorraadformulier in de query de parameter [formulieren]![keuzeformulier]![Medewerkers1] of de paramater [formulieren]![keuzeformulier]![Medewerkers2] werken. Beide in het zelfde formulier tegelijk laten werken gaat niet want dan vind je alleen de zaken waaraan beide medewerkers samen werken. Ik zoek dus de trigger om een parameter aan of uit te zetten en meende dat wellicht het gevuld zijn van een veld (of variabele) die trigger zou kunnen zijn, maar zit dan met de syntax.

Ik hoop dat ik helder ben.

 

[OctaFish]

De query zoekt dus op de naam van de medewerker in de groep (tabel) Medewerkers1. Medewerkers met een andere functie vormen een andere groep (tabel), Medewerkers2,

Dit vind ik héél eng..... Ik kan mij niet voorstellen waarom de medewerkers niet bij elkaar staan in één tabel, en de groepen niet ook in één tabel. En dan een koppeltabel eventueel als één medewerker in meerdere groepen kan zitten. Met jouw constructie zou ik niet uit de voeten kunnen.

 

[EdHa]

Dus een tabel met alle medewerkers met functie als extra veld? En dan een tabel functies met relatie naar medewerkers? Alleen die koppeltabel voor 'dubbelen' is me niet helemaal duidelijk. Je oplossing maakt het leven wel eenvoudiger, maar ik moet wel mijn keuzeformulier aanpassen om de juiste medewerkers te selecteren. Anyway, weer een stapje verder.

 

[OctaFish]

Je hebt hem inderdaad door. Die koppeltabel is alleen nodig als één medewerker in meerdere groepen mag zitten. Is dat niet het geval, dan is een koppeling tussen Medewerker en Functie al genoeg. Dat maakt je formulier als het goed is ook een stuk simpeler.

 

[EdHa]

Het advies van Octafish is juist en behartenswaardig, maar de oplossing van mijn probleem was zelfs in de bestaande situatie (die ik toch maar ga veranderen naar het advies) eenvoudiger dan gedacht. Gewoon met een tweede criterium op de OF-regel. Aangezien bij keuze voor iemand uit medewerkers1 de andere leeg blijft doet het OF-statement wat nodig is. Immers, of aan het ene criterium wordt voldaan, of aan het andere. En dat is wat ik zocht. Zo simpel kan het leven soms zijn.

 

[OctaFish]

Een oplossing die ik je met opzet niet heb gegeven, omdat je veel beter een correcte database kunt maken dan doormodderen op basis van een verkeerd concept. Niet iedereen is dat met me eens hier (als iemand een specifieke vraag stelt, geef dan het antwoord daarop) maar ik zie liever dat je een goede database maakt dan dat je met quick-and-dirty methodes een spaghetti bouwwerkje maakt. .

 

[EdHa]

Je hebt absoluut gelijk dat een goede database te verkiezen is boven spaghetti. Hoewel dat op zijn tijd ook lekker is. In dit geval heb ik de oplossing toch nodig in de nieuwe situatie want ik zal dan ook een query moeten maken die laat kiezen tussen medewerkers. Daartoe gebruik ik het liefst één formulier en niet voor elke optie een ander want je komt op een gegeven moment om in de formulieren als je niet oppast.

 

[OctaFish]

Daartoe gebruik ik het liefst één formulier en niet voor elke optie een ander want je komt op een gegeven moment om in de formulieren als je niet oppast.

Helemaal gelijk. Ik doe niet anders. En dat hoef jij ook niet te doen. Nog steeds dus met een goed opgezette database. Nogmaals: zet je de handel goed in elkaar, dan werkt alles op rolletjes zonder dat je gekke constructies hoeft te verzinnen. En die van jou valt wat mij betreft onder 'gekke constructie' . Ik maak regelmatig formulieren voor verschillende soorten medewerkers. Elke medewerkersgroep krijgt dan een eigen variant van een formulier te zien. En toch zien ze allemaal hetzelfde formulier; op basis van de werkgroep kun je een formulier namelijk prima inregelen. En voor het onderhoud heb je dan ook maar één formulier.

 

[EdHa]

Heb je daar ter leeringh ende vermaeck wellicht een voorbeeldje van? Altijd leuk om van te leren.