Waarde ophalen uit tabel aan de hand van andere waarde op formulier

[Erik191283]

Beste mensen,

Na jaren niets met acces gedaan te hebben ben ik er nu weer mee begonnen en dat gaat niet helemaal vanzelf....

Waar ik nu tegen aan loop is het volgende. In de database moeten contracten bijgehouden worden, deze gaan over een bepaalde hoeveelheid in te leveren artikelen. De hoeveelheid kan in stuks zijn, in uren of in KG (en waarschijnlijk nog wat opties die mij nog niet bekend zijn). Op het moment dat ik op het formulier waarop ik de contracten invoer het artikel kies, zou ik graag willen dat achter het veld hoeveelheid de eenheid komt te staan. Ik heb inmiddels een aantal opties geprobeerd, maar ik krijg het niet voor elkaar, terwijl het volgens mij toch niet heel moeilijk moet zijn. Graag hoor ik of jullie met kunnen helpen. Voor de duidelijkheid heb ik (het begin van) de database bijgevoegd.

Alvast bedankt!

Bekijk bijlage Database2.rar

 

[OctaFish]

Je moet nog een paar aanpassingen maken (naast het gebruik van zinvolle namen; daar ga je vroeg of laat problemen mee krijgen als je dat niet doet).

1. Query aanpassen voor je keuzelijst naar:

SELECT Artikelen.Id, Artikelen.Naam, Artikeleenheden.Eenheid FROM Artikeleenheden INNER JOIN Artikelen ON Artikeleenheden.Id = Artikelen.Eenheid ORDER BY Artikelen.Naam;

2. Het tekstvak waar je de eenheid wilt hebben een Besturingselementbron geven:

=[cboArtikel].[column](2)

En dan zou het moeten werken.

 

[Erik191283]

OctaFish,

Allereerst hartelijk dank! Het werkt inderdaad. Die zinvolle namen is inderdaad een punt ja, vanuit userforms in Excel ben ik dat wel gewend te doen, maar dat was er even bij ingeschoten.

Ik probeer gelijk ook te begrijpen wat ik er in zet, klopt het als ik de volgende conclusie trek:
Select gebruik je om te bepalen welke kolommen je wilt hebben
From gebruik je voor de juiste tabel
Inner Join voor de tweede tabel (die wel een relatie moet hebben met de eerste)
On benoemt die relatie tussen de twee tabellen
Order by noemt de kolom waarop gesorteerd wordt.

 

[OctaFish]

Zo kun je het vertalen, maar het is dan niet helemaal correct.

Select gebruik je om te bepalen welke kolommen je wilt hebben

SELECT gebruik je om het Type query aan te duiden en inderdaad ook om velden te selecteren. Daarnaast heb je bijvoorbeeld actiequeries als DELETE en INSERT INTO. Ook daarbij gebruik je soms SELECT om velden uit tabellen te halen. Select bepaalt echter niet de kolommen; die benoem je apart.

Inner Join voor de tweede tabel (die wel een relatie moet hebben met de eerste)

JE hebt 3 soorten Joins: Inner Join, Left Join en Right Join. De laatste 2 zijn varianten van een Outer Join. Relaties leg je voor het gemak vast in het Relaties scherm, maar die zijn niet noodzakelijk voor een query. Met de gebruikte code wordt hij ter plekke aangemaakt. Het is overigens aan te bevelen om wél al relaties te leggen, al was het maar voor het gemak in je queries. Dan liggen de joins er namelijk al in.

 

[Erik191283]

Bedankt, ben weer een hoop wijzer!

 

[PFL]

Hallo Erik,
Waarom heb je het formulier Contracten gebaseerd op de tabel Contracten i.p.v. de Contracten Query? In de query heb je de Eenheid opgenomen dus die had je dan al gelijk in je formulier gehad.

 

[OctaFish]

Omdat TS vast niet zal willen dat je dat veld kan aanpassen, bijvoorbeeld.

 

[PFL]

Je kan een veld heel eenvoudig blokkeren tegen wijzigingen; een stuk eenvoudiger dan op deze manier.
Maar ik was eigenlijk meer benieuwd naar Erik's beweegredenen.

 

[OctaFish]

Je kan een veld heel eenvoudig blokkeren tegen wijzigingen; een stuk eenvoudiger dan op deze manier.

Echt nie...

 

[Erik191283]

de beweegreden is vrij simpel: onbekendheid met het pakket....

Die query werd gebruikt voor een rapport, nooit erover nagedacht dat die eventueel ook gebruikt zou kunnen worden voor een formulier.

 

[OctaFish]

Dat je je al moet verantwoorden als je iets goed doet .
Je kunt formulieren (en rapporten) op zowel tabellen als rapporten baseren. Met name bij rapporten gebruik je vaak queries op basis van meerdere tabellen; formulieren zijn toch meer bedoeld voor mutaties zoals invoeren van records en wijzigen van gegevens. En dat doe je altijd op basis van één tabel. Daarom gebruik ik zelden queries voor formulieren maar baseer ik een formulier meestal op een tabel.
Ander puntje is dus dat je bij het toevoegen van de verkeerde velden in je query een formulier hebt waarbij je niks meer kunt muteren, en als je het goed doet, je ook velden kunt wijzigen die je misschien helemaal niet wilt wijzigen. Om dat te voorkomen gebruik ik dus (bijna) altijd de techniek die jij nu ook hebt gebruikt: niet-gebonden velden gebruiken die je vult vanuit keuzelijsten.

 

[PFL]

Echt nie...

Ech wel.... Zet de eigenschap 'Vergrendeld' op Ja en klaar is kees...

 

[OctaFish]

Zin in woordspelletjes? Als je meerdere velden wilt doen, moet je ze allemaal apart instellen. Het is dus, in het beste geval, net zo eenvoudig. Maar dat mag bij het ontwerpen van een db nooit een rol spelen.
Bovendien: als je een veld op ,Vergrendeld> zet ziet het het niet geweldig fraai uit. Dus je moet ook de opmaak nog eens instellen. Maar de belangrijkste redenen om het niet via een query te doen heb ik hierboven al uitgelegd.

 

[PFL]

Ik denk dat je nu in de war bent met de eigenschap 'Ingeschakeld'. Als je die op Nee zet, verandert inderdaad de opmaak. Als je 'Vergrendeld' gebruikt, verandert er echter niks aan de opmaak.
Verder vind ik de argumenten die je aandraagt weinig overtuigend. Je kan eenvoudig van meerdere velden tegelijkertijd de eigenschappen instellen.
En dat je aan een query verkeerde velden kan toevoegen waardoor je formulier niet meer werkt.... Ja, dat kan. Je kan ook diesel in je benzine-auto gooien. M.a.w. dat moet je gewoon niet doen
Ik hou het op vergrendelen en als het echt niet anders kan, gebruik ik jouw work around wel. Waarvoor dank, dat dan weer wel. Kan altijd een keer van pas komen

 

[OctaFish]

Mijn methode is geen workaround, maar in mijn ogen de beste methode. Ik zie jou methode als workaround. In feite is elke methode waarbij je extra handelingen moet verrichten om een bepaald resultaat te behalen, zoals velden extra beveiligen, een workaround.

 

[PFL]

Dat is de omgekeerde wereld! Ik gebruik gewoon de eigenschap 'Vergrendeld' waar deze voor bedoeld is. Dat kan ik met de beste wil van de wereld geen workaround noemen.
Met jouw criterium voor een workaround is nou juist jouw methode een workaround!

 

[OctaFish]

Ik kan niet zien hoe deze discussie ook maar iets bijdraagt aan de oplossing voor de TS (die overigens meer dan gelukkig lijkt te zijn met mijn oplossing) dus ik ga hier niet verder op door. Enige tip die ik je kan geven: lees de cursus er nog eens op na (of schrijf een betere) en zoek eens op wat een 'workaround' is. Want volgens mij heb je geen idee wat dat is...