[Access 2007] List Box query data value same row

[KS1987]

Ik heb een tabel met vier kolommen:
kolom kaas, kolom patat, kolom groenten en kolom eten.

Als ik de eerste rij vul in volgorde:
zwitserse kaas, zwitserse patat, zwitserse kool en list box.
Dan wil ik dat de listbox enkel de drie zwitsere opties weergeeft, zelfs als ik in de 2de rij begin met Italiaanse gerechten.

Welke query maak ik daar voor aan? Want tot nu toe krijg ik enkel de mogelijkheid om te kiezen tussen zwitserse kaas of italiaanse kaas als ik een listbox aanmaak.

Alvast bedankt!

[Woy]

Ik denk dat je eerst eens goed na moet denken over je data model.

Een listbox word meestal gevuld door van meerdere rows een column te pakken.

Als datamodel zou ik dan in je eten voorbeeld iets nemen wat meer op het volgende lijkt.

Tabel Land:

• Id
• LandNaam

Tabel Eten:

• Id
• LandId
• EtensNaam

Als query krijg je dan iets van

SQL:

SELECT e.EtensNaam
FROM Eten e
JOIN   Land l
ON e.LandId is l.Id
Where l.LandNaam = 'Zwitserland'

[ Voor 140% gewijzigd door Woy op 06-04-2009 15:22 ]

[KS1987]

Het eten was louter ter illustratie. De oplossing lijkt goed, maar is deze wel bruikbaar om drie kolommen samen te voegen in een listbox. Die drie kolommen bevatten verschillende namen van personen en de listbox mag enkel de namen van die rij weergeven, niet van bovenstaande en/of onderstaande. Dus op rij 41 mag ik enkel de namen zien van rij 41 en niet van bvb rij 82.

[Woy]

KS1987 schreef op maandag 06 april 2009 @ 14:40:
Het eten was louter ter illustratie. De oplossing lijkt goed, maar is deze wel bruikbaar om drie kolommen samen te voegen in een listbox. Die drie kolommen bevatten verschillende namen van personen en de listbox mag enkel de namen van die rij weergeven, niet van bovenstaande en/of onderstaande. Dus op rij 41 mag ik enkel de namen zien van rij 41 en niet van bvb rij 82.

Mijn voorbeeld was ook alleen ter illustratie.

Ik denk gewoon dat je datamodel niet goed is als je meerdere namen in verschillende kolommen hebt staan. Je zou eens kunnen kijken naar Wikipedia: Databasenormalisatie

[KS1987]

Is onderstaand voorbeeld dan niet mooi opgemaakt:

ID | Land | Agent van Dienst | Agent 1 | Agent 2 | Agent 3
1 | Be | listbox | Jan | Dirk | Tom
2 | Fr | listbox | John | Jack | Louis

[Woy]

Ik zou het zo niet aanpakken nee, want stel nou dat je straks een 4e agent wil hebben? Ga je dan een column toevoegen?

Je kan mijn voorbeeld ook gewoon vertalen naar jouw voorbeeld

Tabel Landen:

• Id
• LandNaam

Tabel Agenten:

• Id
• LandId
• Agent Naam
• Agent Geboortedatum

Eventueel zou je er nog een extra koppel tabel tussen kunnen doen als agenten in meerdere landen actief kunnen zijn. Maar dat zijn gewoon standaard dingen als 1:N en N:M relaties.

Op deze manier ben je flexibel en kun je per land zoveel Agents heben als je wil.

[KS1987]

Lijkt me goed, was het niet dat ieder agent een andere functie bekleed en dus een eigen kolom nodig heeft. Bij het ontwerp van deze database moet niet naar de toekomst gekeken worden, het aantal functies is beperkt, dus er kan enkel bvb: anti-diefstal, anti-drugs en anti-vandalisme optreden.

Ik heb twee tabellen aangemaakt:

Tabel 1:
Id:
Agent van Dienst: listbox

Tabel 2:
Agent van Dienst Id:
Agent met functie 1:
Agent met functie 2:
Agent met functie 3:

Iedere rij is een ander land en de agenten mogen enkel in hun land van oorsprong voorkomen.

ps: bedankt voor je geduld

[Woy]

KS1987 schreef op maandag 06 april 2009 @ 15:40:
Was het niet dat ieder agent een andere functie bekleed en dus een eigen kolom nodig heeft.

Ik zie niet hoe een aparte functie iets met een eigen kolom te maken heeft

Bij het ontwerp van deze database moet niet naar de toekomst gekeken worden, het aantal functies is beperkt, dus er kan enkel bvb: anti-diefstal, anti-drugs en anti-vandalisme optreden.

Het lijkt me nogal een vreemde eis dat er niet naar de toekomst gekeken moet worden.

Maar blijkbaar heb je in je huidige design ook al een probleem. Als je een beperkt aantal functies hebt kan je het bijvoorbeeld zo oplossen

Tabel Landen:

• Id
• LandNaam

Tabel Functies

• Id
• FunctieNaam

Tabel Agenten:

• Id
• LandId
• FunctieId
• Agent Naam

Met een unique constraint op LandId/FunctieId

[KS1987]

Het is nog niet volledig hoe ik het voor ogen heb, misschien helpt Tabel 1 & Tabel 2:

Tabel 1:
ID Land Agent van Dienst
1 Italië John
2 Frankrijk Filip
3 Nederland Jaak

Tabel 2:
ID LandId Diefstal Drugs Vandalisme
1 Italië John Joop Jaal
2 Frankrijk Franky Fonz Filip
3 Nederland Jap Jaak Jonny

Dus de functie moet niet vermeld worden, maar is louter ter informatie. De database is beperkt omdat het dienst als een voorstelling, niet voor langdurig gebruik.

[pedorus]

Woy schreef op maandag 06 april 2009 @ 16:12:
[...]

Ik zie niet hoe een aparte functie iets met een eigen kolom te maken heeft

Nou ja, ik zie niet in waarom het fout zou zijn om bij verschillende functies die door 1 persoon vervult worden meerdere velden te gebruiken? Als je bijvoorbeeld een overzicht van projecten met projectleider, vice-projectleider en stakeholder hebt, zou ik ook niet direct een tussentabel gebruiken. Dat lijkt me een beetje overdesign, en je moet dan iedere keer 3 joins doen of een view gebruiken (minder groot probleem). Ik zie in het design in de post hierboven dus niet direct een probleem.

Voor het originele probleem dat je niet alle namen wil laten zien:
Zet in de form de Rowsource als iets met een where-clause die terugverwijst naar de form (select ... where medewerkers.landId = Forms!Landcontactpersonen!landId), en gebruik een event On Enter die Requery() van de combobox aanroept.

[Woy]

Tuurlijk hoef je niet altijd volledig uit te normaliseren. Maar zo complex word het in dit geval IMHO niet. Je bent gewoon veel flexibeler

Als je bijvoorbeeld mijn tabel-structuur aanhoud ( Woy in "[Access 2007] List Box query data value ..." ) is de query die volgens mij moet doen wat de TS zou willen

SQL:

SELECT    a.naam
FROM       Agenten a
INNER JOIN Landen l
    a.LandId = l.Id
WHERE l.naam = 'land'

als je dan de functie-naam erbij zou willen is dat eenvoudig uitgebreid.

Een extra koppel tabel is natuurlijk niet nodig als je zeker weet dat een persoon maar 1 functie kan vervullen.

[pedorus]

Ok, dan zitten we toch op dezelfde lijn Landen is inderdaad typisch iets waarvoor je een (hulp)tabel gebruikt. Met Access hoef je je dan niet eens in joins te verdiepen. Je kan gewoon de Lookup wizard gebruiken als type en Access regelt het vervolgens achter de schermen (volgens mij heeft TS dit al gezien LandId).

[KS1987]

Ik heb de wizard eens geprobeerd en ik kwam goed uit, ik zou nog enkel de constraint er willen in verwerken.

Momenteel heb ik eerst SELECT waarden, gevolgd door ORDER BY

Vervolgens dacht ik aan:
WHERE [Landen].[ID] = [Agenten].[ID];

Maar dat wil niet helemaal lukken. Van functies is het al opgelost, alle drie de agenten worden naast elkaar gegeven. Het is niet ideaal, maar het werkt.

[pedorus]

Die constraint gaat alleen maar werken op een Form, en dan moet je iets gebruiken als

SQL:

SELECT ... FROM ... WHERE Forms!Landen!ID=[Agenten].[LandId] ORDER BY ...

Daarnaast moet je dus Requery in een macro stoppen om het te laten werken, anders wordt de lijst niet geupdate.

Als je een soort grid wil tonen, is een multiple items form (create->forms->multiple items) snel gemaakt als je dat nog niet hebt. Zo´n grid heeft enkel als nadeel dat de combobox op de niet-actieve rijen verkeerd getoond zal moeten worden als je de comboboxlijst aanpast. Je kan wel zoiets doen:

Visual Basic:

Private Sub Diefstal_Enter()
    Diefstal.RowSource = "SELECT ... FROM ... " & _
        "WHERE Forms!Landen!ID=[Agenten].[LandId] ORDER BY ..."
End Sub

Private Sub Diefstal_Exit (Cancel As Integer)
    Diefstal.RowSource = "SELECT ... FROM ... ORDER BY ..."
    Diefstal.Requery 'Redraw
End Sub
... 'ook voor Drugs, Vandalisme

Enkel tijdens het bewerken van een combobox zullen de rijen van andere landen af en toe tijdelijk als leeg getoond worden (om precies te zijn als ze opnieuw getekend worden).

Maar misschien weet er iemand nog een betere oplossing, hoewel ik vrees dat die er niet is

[KS1987]

Ik vrees dat mijn huidig technisch inzicht te beperkt is om deze taak tot een goed eind te brengen. Bedankt voor de hulp, maar ik ga eerst de basics eens moeten nakijken voor verder met dit te proberen.