DAX-fout "A table of multiple values" oplossen (2026)

De fout “A table of multiple values was supplied where a single value was expected” betekent dat een DAX-expressie meerdere tabelwaarden oplevert op een plek waar exact één scalar nodig is. Kies de oplossing op basis van je bedoeling: één selectie met SELECTEDVALUE, rijen tellen met COUNTROWS, waarden samenvatten met een iterator, een tekstlijst maken met CONCATENATEX of de tabel als filterargument gebruiken.

Wat gaat er precies mis?

DAX kent naast tekst, getallen, datums en andere scalaire waarden ook tabellen. Functies zoals VALUES, DISTINCT, FILTER, TOPN, SUMMARIZE en SELECTCOLUMNS kunnen een tabel retourneren. Dat is geldig zolang de volgende functie daar een tabel verwacht.

Geeft de tabelexpressie meerdere kolommen terug, bijvoorbeeld bij FILTER over een volledige modeltabel, begin dan met de decoder voor “Multiple columns cannot be converted to a scalar value”. Deze pagina richt zich op de volgende cardinaliteitsvraag: de ontvangende plek verwacht één waarde, maar een eenkolomstabel of lookup kan meerdere waarden opleveren.

Een measure moet uiteindelijk één scalar aan de visual geven. Ook een vergelijking, rekenkundige bewerking of tekstsamenvoeging heeft aan iedere kant een passende scalaire waarde nodig. Geef je daar een tabel met meerdere resultaten door, dan kan DAX niet zelf bepalen welke waarde je bedoelt.

De melding lijkt op de DAX-fout “A single value for column cannot be determined”, maar het diagnosepunt verschilt. Bij die fout staat vaak een losse kolomverwijzing in een measure. Bij deze fout zoek je vooral naar een tabelfunctie, een tabelvariabele of een lookup die meerdere verschillende uitkomsten kan opleveren.

Kies eerst welk resultaat je nodig hebt

Gebruik niet automatisch MAX of FIRSTNONBLANK om de fout te onderdrukken. Stel eerst vast wat de rapportgebruiker moet zien.

• Precies één geselecteerde categorie: gebruik SELECTEDVALUE.
• Het aantal gevonden rijen: gebruik COUNTROWS.
• Een totaal over gevonden rijen: gebruik SUMX of een aggregatie binnen CALCULATE.
• De hoogste of laatste waarde volgens een echte regel: gebruik MAXX of een deterministisch TOPN-patroon.
• Alle zichtbare waarden als tekst: gebruik CONCATENATEX.
• Een tabel die alleen een berekening moet filteren: geef de tabel aan CALCULATE of CALCULATETABLE.
• Eén waarde uit een andere tabel: maak de zoeksleutel uniek of gebruik een geldige relatie met RELATED.

Volgens het officiële DAX-overzicht van Microsoft worden tabelfuncties meestal als tussentabel gebruikt en vervolgens geteld, gefilterd of geaggregeerd. De tabel rechtstreeks als eindresultaat van een measure gebruiken is dus niet het doel.

Stap voor stap de multiple-values-fout oplossen

1. Zoek waar één scalar wordt verwacht

Begin bij de measure, berekende kolom of het functieargument dat de fout geeft. Controleer vooral:

• de expressie na het gelijkteken van een measure;
• een argument van IF, een operator of een tekstsamenvoeging;
• het eerste argument van CALCULATE;
• de resultaatkolom en zoekvoorwaarden van LOOKUPVALUE;
• de eindexpressie na RETURN.

Schrijf op welk gegevenstype daar hoort te staan. Een kaarttitel vraagt tekst, een aantal vraagt een geheel getal en een measure moet één scalar opleveren. Een tabelvariabele mag wel bestaan, zolang je die vóór RETURN bewust reduceert of als tabelargument gebruikt.

2. Zoek de functie die een tabel retourneert

Scan de formule op VALUES, DISTINCT, FILTER, TOPN, ALL, SUMMARIZE, SELECTCOLUMNS en CALCULATETABLE. Controleer de retourwaarde in de DAX-functiereferentie als je twijfelt.

Let ook op variabelen:

VAR ZichtbareCategorieen = VALUES(Product[Categorie])

ZichtbareCategorieen is hier een tabelvariabele. De variabelenaam zegt niets over het type. De fout ontstaat pas wanneer je deze tabel op een plek gebruikt waar één waarde nodig is.

3. Tel de resultaten tijdens de diagnose

Maak tijdelijk een controlemeasure voor het aantal rijen of onderscheidende waarden:

Aantal zichtbare categorieën =
COUNTROWS(VALUES(Product[Categorie]))

Test die measure zonder selectie, met één selectie, met meerdere selecties en op de totaalrij. Een uitkomst groter dan 1 verklaart waarom een impliciete omzetting naar één waarde niet kan werken.

Voor een gefilterde tabel kun je hetzelfde patroon gebruiken:

Aantal open orders =
COUNTROWS(
    FILTER(
        Orders,
        Orders[Status] = "Open"
    )
)

COUNTROWS levert één scalaire uitkomst op: het aantal rijen, of BLANK() wanneer de tabel leeg is. Zo zie je hoeveel rijen je filter werkelijk vindt; gebruik zo nodig COALESCE(..., 0) als je expliciet nul wilt tonen.

4. Kies een bewuste omzetting of gebruik de tabel als tabel

Bepaal nu of je één waarde, een aggregatie, een telling, een tekstlijst of een filter nodig hebt. Pas alleen het kleinste relevante blok aan. Laat de controlematen tijdelijk in een testvisual staan zodat je ziet hoe de context verandert.

5. Test nul, één en meerdere resultaten

Een goede reparatie behandelt alle verwachte situaties:

1. de tabel bevat geen rijen;
2. de tabel bevat één rij of één onderscheidende waarde;
3. de tabel bevat meerdere rijen met dezelfde resultaatwaarde;
4. de tabel bevat meerdere verschillende resultaatwaarden;
5. de visual evalueert een totaal in plaats van een detailrij.

Controleer daarnaast of slicers, paginafilters en modelrelaties de hoeveelheid gevonden data veranderen. Gebruik het overzicht met DAX-foutmeldingen als Power BI na de reparatie een andere context-, relatie- of datatypefout toont.

Oplossing 1: één selectie ophalen met SELECTEDVALUE

Deze measure retourneert met VALUES een tabel:

Gekozen categorie = VALUES(Product[Categorie])

Een tabel met precies één kolom en één rij kan DAX in sommige expressies impliciet als scalar behandelen. Daardoor kan deze measure bij één zichtbare categorie lijken te werken. Zodra meerdere categorieën zichtbaar zijn, kan DAX de tabel niet meer tot één scalar herleiden. Gebruik:

Gekozen categorie =
SELECTEDVALUE(
    Product[Categorie],
    "Meerdere categorieën"
)

SELECTEDVALUE geeft de kolomwaarde terug wanneer de filtercontext precies één onderscheidende waarde bevat. Bij nul of meerdere waarden geeft de functie het alternatieve resultaat terug, of BLANK() wanneer je dat argument weglaat. De officiële SELECTEDVALUE-documentatie beschrijft dit gedrag.

Gebruik deze oplossing alleen als één selectie de businessregel is. Wil je alle categorieën tonen, dan heb je geen selectie maar een tekstlijst nodig.

Oplossing 2: rijen tellen of waarden aggregeren

FILTER retourneert een tabel en hoort daarom niet rechtstreeks als eindresultaat van een measure:

Open orders =
FILTER(
    Orders,
    Orders[Status] = "Open"
)

Wil je het aantal open orders, gebruik dan COUNTROWS:

Open orders =
COUNTROWS(
    FILTER(
        Orders,
        Orders[Status] = "Open"
    )
)

Wil je een numerieke kolom over de gevonden rijen optellen, gebruik dan een iterator:

Open aantal artikelen =
SUMX(
    FILTER(
        Orders,
        Orders[Status] = "Open"
    ),
    Orders[AantalArtikelen]
)

FILTER levert de rijen en SUMX evalueert de tweede expressie per rij en levert uiteindelijk één som op. Kies MAXX, MINX of AVERAGEX alleen wanneer die samenvatting inhoudelijk past.

Oplossing 3: de tabel als filterargument gebruiken

Een tabel hoeft niet altijd naar een scalar te worden omgezet. In CALCULATE mag een tabeluitdrukking als filterargument dienen:

Te late orders =
CALCULATE(
    [Aantal orders],
    FILTER(
        Orders,
        Orders[Leverdatum] < TODAY()
            && Orders[Status] <> "Geleverd"
    )
)

Het eerste argument van CALCULATE is een scalaire expressie, hier de measure [Aantal orders]. FILTER staat op de juiste plek als tabelargument en wijzigt de filtercontext waarin de measure wordt berekend.

Voor eenvoudige voorwaarden op kolommen uit één tabel zijn directe booleaanse filterargumenten meestal duidelijker en efficiënter. Gebruik FILTER als de logica werkelijk een tabelscan of een complexere voorwaarde nodig heeft. FILTER is dus niet verboden in CALCULATE; de positie en bedoeling bepalen of het past.

Moet de einduitkomst zelf een tabel zijn, bijvoorbeeld voor een berekende tabel of als invoer voor een andere tabelfunctie, gebruik dan waar passend CALCULATETABLE. Microsoft legt het verschil uit bij CALCULATE en CALCULATETABLE.

Oplossing 4: meerdere waarden tonen met CONCATENATEX

Voor een dynamische titel wil je soms alle zichtbare categorieën tonen. Maak dan één tekstwaarde:

Zichtbare categorieën =
CONCATENATEX(
    VALUES(Product[Categorie]),
    Product[Categorie],
    ", ",
    Product[Categorie],
    ASC
)

VALUES levert de tabel en CONCATENATEX evalueert de categorie per rij. Het resultaat is één tekstscalar. Geef een sorteerkolom en volgorde op, want zonder orderBy_expression is de volgorde van de samengevoegde waarden niet gegarandeerd.

Bij veel categorieën kan een titel onleesbaar worden. Toon dan bijvoorbeeld eerst het aantal waarden of gebruik een korte alternatieve tekst. De officiële CONCATENATEX-documentatie bevestigt dat de functie een tabel verwerkt en één samengevoegde tekenreeks retourneert.

Oplossing 5: LOOKUPVALUE en dubbele sleutels herstellen

Deze berekende kolom in Verkoop zoekt een productgroep:

Productgroep =
LOOKUPVALUE(
    ProductMapping[Groep],
    ProductMapping[Productcode],
    Verkoop[Productcode]
)

Als meerdere regels dezelfde productcode hebben en verschillende groepen teruggeven, bestaat er geen unieke uitkomst. Controleer eerst de brondata. Vaak hoort Productcode uniek te zijn in een productdimensie.

De beste structurele oplossing is meestal:

1. maak de sleutel aan de één-kant uniek;
2. leg een geldige veel-op-één-relatie vast;
3. haal de waarde in een berekende kolom op met RELATED.

Productgroep = RELATED(Product[Groep])

RELATED vereist rijcontext en kan geen beperkte relatie volgen. Gebruik deze variant daarom in een berekende kolom of binnen een iterator, en alleen wanneer het model een geschikte reguliere veel-op-één-relatie bevat.

Moet de combinatie van productcode en regio werkelijk uniek zijn, voeg dan het tweede zoekcriterium toe:

Productgroep =
LOOKUPVALUE(
    ProductMapping[Groep],
    ProductMapping[Productcode],
    Verkoop[Productcode],
    ProductMapping[Regio],
    Verkoop[Regio]
)

Een belangrijke nuance: meerdere gevonden rijen zijn niet automatisch een fout. Als al die rijen in de resultaatkolom exact dezelfde waarde bevatten, retourneert LOOKUPVALUE die waarde. Verschillen de resultaten, dan volgt een fout of het opgegeven alternateResult. Gebruik zo'n alternatief niet om een onbedoelde dubbele sleutel stil te verbergen. Zie de officiële uitleg van LOOKUPVALUE.

Oplossing 6: TOPN reduceren tot een scalar

TOPN retourneert ook bij N = 1 een tabel. Deze measure is daarom niet compleet:

Laatste status =
TOPN(
    1,
    Statushistorie,
    Statushistorie[Datum],
    DESC
)

Maak eerst de bedoelde rijselectie en lees daarna één waarde met een iterator uit:

Laatste status =
VAR GekozenOrder = SELECTEDVALUE(Orders[OrderId])
VAR LaatsteRij =
    TOPN(
        1,
        FILTER(
            Statushistorie,
            Statushistorie[OrderId] = GekozenOrder
        ),
        Statushistorie[Datum],
        DESC,
        Statushistorie[StatusId],
        DESC
    )
RETURN
    IF(
        ISBLANK(GekozenOrder),
        BLANK(),
        MAXX(LaatsteRij, Statushistorie[Status])
    )

De tweede sortering maakt de keuze eenduidig wanneer meerdere statusregels dezelfde datum hebben, mits StatusId uniek is. Dat is belangrijk, want TOPN kan bij een gelijke sorteerwaarde op de grens meer dan N rijen retourneren. MAXX zet de overgebleven rij om in één scalar. Gebruik een ander patroon wanneer “laatste” geen geldige inhoudelijke keuze is.

Let op bij DirectQuery

De gebruikte functies zijn niet algemeen verboden in DirectQuery. Microsoft documenteert dit per functie, bijvoorbeeld bij VALUES en CONCATENATEX: ze zijn in DirectQuery niet ondersteund in berekende kolommen en RLS-regels.

Measures vallen niet automatisch onder dat verbod. Krijg je de fout in een DirectQuery-berekende kolom, controleer dan naast de tabel-scalarlogica ook of de functie in die context wordt ondersteund. Verplaats de berekening zo nodig naar de databron, Power Query of een measure.

Veelgemaakte fouten

• Blind MAX of MIN toevoegen. De fout verdwijnt, maar de gekozen uiterste waarde kan inhoudelijk willekeurig zijn.
• Vergeten dat VALUES een tabel retourneert. Ook bij één zichtbare waarde blijft het retourtype een tabel.
• FILTER rechtstreeks als measure teruggeven. Geef de tabel aan COUNTROWS, een iterator of als filterargument aan CALCULATE.
• TOPN(1) als scalar behandelen. TOPN retourneert een tabel en kan door gelijke sorteerwaarden zelfs meer dan één rij teruggeven.
• Een LOOKUPVALUE-alternatief gebruiken zonder de sleutel te onderzoeken. Zo kan een modelprobleem onzichtbaar blijven.
• Alleen de detailrij testen. Een totaalrij heeft vaak een bredere context en kan daardoor meer waarden opleveren.
• Een tekstlijst zonder sortering maken. CONCATENATEX garandeert zonder sorteerveld geen vaste volgorde.
• Rijen en onderscheidende waarden verwarren. Meerdere rijen met dezelfde lookup-uitkomst kunnen geldig zijn; verschillende resultaatwaarden zijn het probleem.

Zo voorkom je deze fout

Geef tabelvariabelen een herkenbare naam, zoals GefilterdeOrders of ZichtbareCategorieenTabel. Geef scalaire variabelen namen als AantalOrders of GekozenCategorie. Controleer in de DAX-referentie altijd het retourtype van een onbekende functie.

Ontwerp dimensietabellen met een unieke sleutel aan de één-kant en valideer die sleutel al tijdens het laden. Test nieuwe measures in een controletabel met het aantal gevonden rijen en onderscheidende waarden. Zo zie je vroeg wanneer een berekening van één naar meerdere resultaten gaat.

Wil je beter begrijpen waarom Excel-logica niet rechtstreeks hetzelfde werkt, lees dan Excel-formules naar DAX vertalen. Loop je tegen een rode parsermelding aan, gebruik dan de decoder voor “The syntax for ... is incorrect”. Alle volgende foutdecoders en modelhandleidingen staan op de Power BI-hub.