Access 2003 Complex Query

[Verwijderd]

Beste Lezer,

ik ben een database aan het maken, waarbij het zoekscherm gebruik maakt van een complexe query. De database is een productendatabase. Ieder product heeft zo zijn naam, groep etc. Maar in ieder product zitten bepaalde stoffen, additieven genoemd. Nu is het ook zo dat ieder additief weer in een ander product kan zitten. Een veel op veel relatie: .
Nu is het zo dat in het formulier gezocht moet kunnen worden op alle eigenschappen van het product. Alles werkt goed, behalve de additieven. Ik kan de additieven wel werkend krijgen, maar dan krijg ik dubbele records.

CT#, ProductCode en Sample# samen zijn de sleutel, die moeten uniek blijven, nadat de gebruiker gezocht heeft op de producten. De additieven hoeven niet direct in de selectiequery getoond te worden, maar moeten wel gebruikt worden om op te selecteren. Waar de additieven wel getoond kunnen worden is bijvoorbeeld in een subquery.

Heeft iemand een idee hoe ik dit aan ga pakken?
Ik heb het geprobeerd met Left/Right joins, met unieke records/value's optie. Allen tevergeefs.
Het zou mij zo enorm helpen als iemand hier een antwoord op had. Ik ben er al best wel lang mee bezig, zonder enige progressie. Mijn kennis over Access is niet groot genoeg om dit op te lossen.
Als er meer informatie nodig is van de database kan ik dit zeker geven.

Alvast heel erg bedankt!

[Marko_J]

"Ik heb het geprobeerd met Left/Right joins, met unieke records/value's optie. Allen tevergeefs."

Ook Group By geprobeerd? Daarmee hou je alleen unieke records over.

[Verwijderd]

Hey bedankt voor je antwoord.
Ik heb idd ook Group by geprobeerd. Maar dit werkt niet denk ik omdat de query voor ieder product de additieven wil laten zien. Dus als er 3 additieven zijn in 1 product, zijn er 3 regels zichtbaar van hetzelfde product. Dit zou ik graag terugbrengen naar 1 regel, waarbij er de mogelijkheid is om op het plusje te drukken vooraan de regel om de additieven weer te geven (via subquery).

De query die ik gebruik is als volgt:


Ik kan hierbij de show weghalen, echter als ik dat doe is het niet meer mogelijk om er op te selecteren in mijn formulier. In plaats dat het daarvoor bestemde veld gebruikt word, komt er een parameter popup met de vraag welk additief (name) op welk additief geselecteerd moet worden.

[ Voor 21% gewijzigd door Verwijderd op 12-05-2010 14:33 ]

[pedorus]

Dit formulier ziet er zodanig lastig uit dat je waarschijnlijk de sql handmatig wil maken/de property filter handmatig met vba-code wil instellen (met zogenaamde in-subqueries in het laatste geval). Verder is waarschijnlijk een master/detail-view het handigst.

[Verwijderd]

Ik ben idd ook al bezig met vba code. Helaas is programmeren niet mijn sterkste kant.
Ik zal ook eens kijken naar master/detail. Bedankt!

[Verwijderd]

Is er misschien wel een mogelijkheid dat iemand kijkt naar de structuur van de database? Is deze juist genormaliseerd? Want ik heb natuurlijk best wel grote sleutels (3 en 4 velden voor een pk). Maar dit komt omdat iedere test (ct) meerdere producten kan bevatten. En ieder product meerdere monsters (samples). Daarnaast is het ook weer zo dat ieder monster meerdere toevoegingen (additieven) kan bevatten. Iemand die mij hier wat wijsheid over kan schenken?

[pedorus]

Ik zou dit niet zo doen. In jouw design neemt bij iedere one-many relatie het aantal sleutelvelden met 1 toe. Dat lijkt me eigenlijk niet zo handig. Kan in tblTest #Sample een primary key zijn? Zo nee, of ook maar bij een klein beetje twijfel zou ik een aparte surrogate id maken, die access trouwens ook al automatisch voor je wil maken (id als autonumber). tblsolution hoeft dan alleen maar naar sample# te verwijzen, en niet naar 3 velden.

In principe is er trouwens niet per se iets mis bij grotere sleutels, maar joins zijn net iets minder efficiënt/makkelijker te maken, het leidt tot herhaling van data, en het is lastiger wijzigen. Ik raad aan om gewoon altijd een enkelvoudige id te hebben (behalve bij koppeltabellen voor many-many relaties), en bij maar de minste twijfel gewoon een surrogate Id. Weet je bijvoorbeeld niet altijd de ProductCode direct bij het invoeren, dan kun je dat nu niet zomaar invoeren (of je moet tijdelijk een foute code neerzetten ). Bij een ProductId heb je dat probleem niet.