Multivalue Field waarden in 1 veld weergeven

Goedemiddag,

Access 2021, Engelstalig.
Ik heb een multivalued field. Daar sla ik ID's uit een andere tabel in op.
Als ik dit multivalued field in een query open kan ik de ID's in 1 veld zien staan, met een punt-komma er tussen.
Als ik in de query de ID's vervang voor de omschrijvingen krijg ik het niet voor elkaar om deze omschrijvingen in 1 veld te zien, gescheiden door een punt-komma.

In het plaatje onderin, (het Formulier Overzicht in datasheet vorm) zie je 'Broodje' en 'Salade' uitgesmeerd over meerdere regels. Deze moeten elk in 1 regel te zien zijn, met de ingrediënten in 1 veld.


In de bijlage het database-bastandje dat je in het screenshot ziet.

Met vriendelijke groet, Visara

Laat ik je snel uit de brand helpen: dat kán ook niet. Ik weet niet of je een moverende redenen hebt om voor deze constructie een Multi-Value veld te gebruiken. Mijn advies: loop daar in eerste instantie met de grootst mogelijke bogen omheen en gebruik ze pas als het écht niet anders kan (meestal wel dus).

Waarom kan het niet? een MVF is eigenlijk een 'interne' tabel met een één-op-veel relatie met de brontabel. Met de eigenschap dat je in die tabel maar één veld hebt. De waarden uit de verschillende 'records' kúnnen in één samengevoegd veld getoond worden, zoals je in de tabel zelf ziet. Maar zodra je aan die tabel een andere tabel koppelt, zoals je doet met de tabel tblIngredienten, dan krijg je dus een 'gewone' query met een één-op-veel relatie. Je kunt dat al simpel simuleren door alleen de tabel tblProduct in een query te zetten, en daarin het veld [ID] te zetten en het veld [Ingrediënten]. Je ziet dan wat je in je tabel óók ziet. Vervang nu het veld [Ingrediënten] door het veld [Ingrediënten.Value], en je krijgt een hele andere output: die van een query met één-op-veel relatie. Met dus net zoveel records per ID als er waarden zijn in het MVF. En dát is dus óók het resultaat als je er de tabel tblIngredienten aan hangt.

De enige 'oplossing' is (maar die geldt voor al dit soort gerelateerde velden, niet alleen voor MVF) om een procedure te maken die de tabel tblIngredienten uitleest, en alle waarden in één tekstveld in de query zet. Hoop werk.... En vermoedelijk zou je het voor een gewone tabel óók nooit doen .

Droevig nieuws, maar ik was er al bang voor. Bedankt voor uw uitleg, ik begrijp het grotendeels denk ik.

Zou u zo vriendelijk willen zijn te kijken of mijn alternatieve route enigszins hout snijdt?

Mijn eerste ingeving is om dan maar meerdere velden beschikbaar te stellen voor ingrediënten in de tblProduct. Ipv een MVF, dus meerdere velden.
Mijn echte database gaat niet over eten trouwens, maar was een heldere vergelijking. Om in de analogie te blijven: er bestaan maar 5 ingrediënten, wellicht in de toekomst uitgebouwd naar bijv +-7. Is te overzien.
Ik heb een opzet gemaakt, zie bijlage02 voor het database bestand.


Het doel is een lijst van de Producten in een overzicht te krijgen met de Ingrediënten in 1 veld. Kan nu.
Een ander doel is de ingrediënten van een Product in 1 string via Word-Merge in een Word bestand krijgen. Zou nu kunnen.
Een ander doel is om een overzicht te krijgen van alle producten met ingrediënt X. Zou kunnen.

Met vriendelijke groet,
Visara

Visara,

Bekijk bijlage Visara_Multivalued_fieldsPl.zip

Zoiets,

maar het blijft geen fijne optie om een MVF te gebruiken.


Gr. Cor

Met een aanpassing van de keuzelijst kun je de gegevens overigens nog wel netjes krijgen, heb ik ontdekt. Kwestie van de eerste kolom verbergen. Was dus toch wat makkelijker dan ik dacht .
Neemt niet weg dat ik je blijf aanraden om er met een grote boog omheen te lopen.

Waarom niet gewoon een tabel ingrediënten met een één op veel relatie naar producten? Volgens mij veel gemakkelijker in het gebruik en je krijgt een genormaliseerde structuur. En als een ingrediënt ook als product bestaat met op zich ook ingrediënten, dan maak je toch gewoon een klassieke BOM structuur? Klassiekers zijn klassiek voor een reden

Die tip heb ik al gegeven in bericht #2.

Bedankt voor jullie reacties.
Ik heb al een 1-to-many relatie in mijn eerste geposte bestand staan. #1

In het bestand van Pletter in #4 lijkt alles te werken zoals ik wil, maar het koste me moeite om te zien wat er nou aan de hand is. Eerst dacht ik dat Pletter ipv de ID, de tekstwaarde in het MVF plaatste. Dat veld is echter een Number field, dus ik begreep niet hoe dat kan. Uiteindelijk kwam ik er uit: In het MVF is de kolombreedte van de kolom met ID op 0cm gezet. Dat 'trucje' ken ik van comboboxen, maar ik was nooit op het idee gekomen dat dit hier zou kunnen werken.
Ik begrijp nu met terugwerkende kracht de uitleg in #2 beter, ik pikte dit er in eerste instantie niet uit.
Dankjulliewel!

Voor geïnteresseerden:
Als ik het allemaal goed overzie is het antwoord op mijn vraag:
ga naar de tabel waar het MVF staat en ga naar de Lookup-tab. Zet de column-width van de kolom met ID op 0cm. Dat zetten van de breedte op 0cm werkt door in query's. Merk op dat MVFs niet echt wenselijk zijn, gedoe is niet uit te sluiten

Ik heb dezelfde 'truc' gebruikt (het is natuurlijk geen truc) in mijn bestandje voor zowel rapport als formulier. Die heb je dan dus niet bekeken . Veel meer oplossingen zijn er ook eigenlijk niet. Ja, geen MVF gebruiken...

Bij die van u staat het ook idd.
Ik begon de reacties chronologisch door te nemen, op die van pletter stuitte ik als eerste.

Visara zei:

Mijn eerste ingeving is om dan maar meerdere velden beschikbaar te stellen voor ingrediënten in de tblProduct. Ipv een MVF, dus meerdere velden.

Klik om te vergroten...

Dat is zo mogelijk een nóg slechter idee dan een MVF . Al was het maar omdat je jezelf al op voorhand beperkt tot een maximaal aantal producten (namelijk: het aantal velden). In alle Access (en database) cursussen leer je dat je dat dus nooit moet doen. Altijd dus een aparte tabel maken voor herhalende gegevens (zoals je ingrediënten) en met een één-op-veel relatie koppelen aan de hoofdtabel. Op die manier is er geen beperking aan het aantal artikelen, en je database blijft hanteerbaar. Ook noella zit op dit spoor, zoals je gelezen hebt.
Op naar ingeving twee dus .

Ik was er zelf ook niet gelukkig mee, heel prettig dat dit niet nodig is.

Het was nooit nodig, maar een of andere nitwit bij Microsoft vond dat jij en ik niet zonder konden .

FYI: volgens de mensen bij microsoft zelf werd dit heel vaak gevraagd door de gebruikers zelf en hebben ze uiteindelijk toegegeven. Zij beschouwen Access niet echt meer als een database product, maar als een applicatie waar ze in feite van af willen.

Ik heb wel eens in testgroepen gezeten voor Microsoft, maar nog nooit iemand dit soort onzin horen uitspreken. Gebruikers vragen natuurlijk nooit om functies waarvan ze het bestaan niet weten, en die in de database wereld ook helemaal niet gebruikelijk zijn. Geen enkel pakket heeft dit soort 'mogelijkheden', dus niemand kan ze ergens gezien hebben. En er dan ook nog eens om gaan vragen bij Microsoft? Lijkt mij héél sterk...

In het pakket filemaker hebben ze multivalue fields en in PostgreSQL heten ze arrays.

Nu ook even het marktaandeel van FileMaker erbij zetten, en dan is het plaatje compleet. En dan moesten we maar stoppen met dit getheoretiseer.... Heeft allemaal (uiteraard) ook weer niets met een antwoord op welke vraag dan ook te maken.

Natuurlijk heeft dit niets te maken met MVF.
Natuurlijk zijn er geen andere programma's die MVF gebruiken.
Natuurlijk heeft het geen zin om zo'n topic te starten over MVF.
Natuurlijk mag je geen discussie voeren over MVF.
Natuurlijk is MVF erg goed ontwikkelt.
Natuurlijk wat ontbekend is eet men en zeker MVF.

Zou MVF een alias van OTV zijn.

Welterusten MVF.

Groet, Cor

BBB Cor. Zó fijn dat allerlei helpers mee willen helpen om draadjes vol te bouwen met onzin berichtjes. En ja, daar doe ik uiteraard ook graag aan mee, want waarom niet?