[Access] Waarde pulldown1 gebruiken in voorwaarde pulldown2

[jotheman]

Ik ben dus Bzig voor stage met een klein databeestje om eenvoudig computeronderdelen in te kunnen voeren.
Het zit dus zo inelkaar dat ik dmv. pulldown-menuutjes de locatie van, het soort (videokaart, monitor, printer enz.) en het type (bv. Sb Live! 1024, Compaq V700 enz.) kan selecteren.
Nu ben ik het dus zo aan het maken dat wat je bij het soort onderdeel selecteert (pulldown1) doorwerkt in pulldown2 en je dus alleen de type onderdelen te zien krijgt van het soort onderdeel wat je ij pulldown1 geselcteerd hebt.
Dit door middel van deze SQL:
SELECT [Type ID].[Typen onderdelen]
FROM [Type ID]
WHERE ((([Type ID]![Soort ID])=[Soort ID]![Soort ID]));
Dit werkt maar half (gegarandeerd dat ik wat fout doe natuurlijk ). Ik kan dus iets aanklikken bij soort en dan naar type gaan, maar daar moet ik nogmaals het soort onderdeel aangeven (hij pakt dit dus niet over vanaf pulldown1). Heeft iemand enig ID hoe ik de waarde van pulldown1 in de voorwaarde van pulldown2 kan gebruiken?
(k heb er dus een mini-query - tje ingezet die kijkt in het tabelletje type-id per type of deze aan de voorwaarde soort voldoet, dit dmv. een controle te doen op het nummer soort-id)

Weet iemand wat ik bedoel en hoe ik dit kan oplossen? (Mag niet maartoch:) Alvast bedankt!

[Verwijderd]

Zou je hier geen INNER JOIN gaan gebruiken?

Voorbeeld van een INNER JOIN:

SELECT tNews.*, tUsers.UserNick FROM tNews INNER JOIN tUsers ON tNews.PostBy = tUsers.id WHERE Hot = 1 ORDER BY tNews.id DESC

Je linkt hier dus de PostBy met de tUsers.id

[ Voor 71% gewijzigd door Verwijderd op 18-03-2003 13:41 ]

[ATS]

Het handigste is gewoon even in VBA te gaan hacken en in het change event van je eerste dropdown de source van de tweede dropdown aan te passen.

[ Voor 11% gewijzigd door ATS op 18-03-2003 13:43 ]

[Verwijderd]

Is eigenlijk vrij simpel:

je select statement met where moet geen probleem zijn, alleen moet je me.requery doen om de eerste keuze door te voeren.

Wat je ook kan doen is on event after update van de eerste keuze

code:

me.blablaveld.value = me.keuze1.value
me.requery

dan in de 2e keuzekox where ...... = me.blablaveld.value

Op deze manier borg je de keuze.

[jotheman]

Bedankt voor de antwoorden, ik ben n.a.v. daarvan aan de slag gegaan en heb weer flink liggen ruziën met access .
Met een INNER JOIN krijg ik het niet voorelkaar, dit i.v.m. de aparte opbouw van mijn database (die leek mij zelf het handigst, maar blijkt nu toch minder handig te worden ).

Het zit namelijk zo:
Ik heb een algemene tabel met de eigenschapppen van ieder product los (met een onderdeel_id, uniek, per onderdeel). Deze laat ik dus invullen d.m.v. een form, hierin kan ik het soort onderdeel (monitor, computer, printer enz.)opgeven (een tekstvak met selectie-mogelijkheid). Aan de hand van dat soort onderdeel wordt uit de tabel Soort_ID het bijbehorende unieke Soort_ID uitgezocht. In het voilgende tekstvak van het form kan men het type dus selecteren, maar dit moet dus op basis van het Soort_ID gaan.
In de lijst van types onderdelen hebben alle verschillende waardes hun eigen eigenschappen m.b.t. de soort en hebben dus een soort_ID gekregen.
Dit is als volgt gekoppeld:



Via Skyper's aanwijzigingen heb ik dit dus veranderd, maar nu heb ik nog het volgende probleem: ik moet nog steeds als ik een soort onderdeel heb aangeklikt en klik op type onderdeel (de slecteer-lijst) een Soort_ID opgeven, het is dus blijkbaar niet geconverteerd van een tekst naar een nummer.
Zou iemand mij kunnen vertellen hoe ik dit voorelkaar krijg?
Ik heb nu het volgende SQL stukje bij Na Bijwerken (After Update) staan:

code:

Private Sub Soort_onderdeel_AfterUpdate()
Me.pulldown1.Value = Me.Soort_onderdeel.Value
Me.Requery
End Sub

Bij het type onderdeel pulldown menuutje heb ik deze SQL bij Rijbron staan:

code:

SELECT [Type ID].[Typen onderdelen] FROM [Type ID] WHERE ([Type ID]![Soort ID]=me.pulldown1.value);

het zit als volgt inelkaar qua relaties:


Alvast heel hartelijk dank voor de hulp!!!

[whoami]

Hmm....

Ff wat opmerkingen over je datamodel:

Waarom heeft de tabel SoortId geen PK?
Waarom gebruik je geen referentiele integriteit bij de relaties?
Waarom heeft de tabel TypeID geen PK?

[jotheman]

whoami schreef op 20 maart 2003 @ 11:39:
Hmm....

Ff wat opmerkingen over je datamodel:

Waarom heeft de tabel SoortId geen PK?
Waarom gebruik je geen referentiele integriteit bij de relaties?
Waarom heeft de tabel TypeID geen PK?

Omdat ik d8 dat PK's niet nodig waren in tabelletjes waar alleen maar gegevens uit werden gehaald of omgezet... zit daar veel voordeel in dan?, Zou ik dan meer kunen o.i.d.?
En referentiële integriteit is dat nodig?, dat kan ik zo doen als dat handig is

[whoami]

PK's heb je in iedere tabel nodig, zo kan je een record uniek identificeren en voor de integriteit van je gegevens zorgen. Daardoor kan je ook ref. integriteit afdwingen.
Hoe bedoel je, ref. int. kan je zo doen? Waarom laat je het niet door je database afdwingen? Laat de DB doen waarvoor hij gemaakt is.
En waarom zou het niet nodig zijn? Zou jij graag orders hebben in je databank voor een klant die al uit de klantentabel gewist is?
Opzoeken op een PK gaat ook altijd het snelst.