Algemene problemen
U kunt ervan uitgaan dat als u uw gegevens sorteert, alle downstreambewerkingen de sorteervolgorde behouden.
Als u bijvoorbeeld een verkooptabel sorteert, zodat de grootste verkoop van elke winkel eerst wordt weergegeven, kunt u verwachten dat als u de bewerking Dubbele waarden verwijderen alleen de hoogste verkoop voor elke winkel retourneert. En deze bewerking lijkt in feite te werken. Dit gedrag is echter niet gegarandeerd.
Vanwege de manier waarop Power Query bepaalde bewerkingen optimaliseert, waaronder het overslaan of offloaden naar gegevensbronnen (die hun eigen unieke volgordegedrag kunnen hebben), is de sorteervolgorde niet gegarandeerd behouden via aggregaties (zoals Table.Group
), samenvoegingen (zoals Table.NestedJoin
) of dubbele verwijdering (zoals Table.Distinct
).
Er zijn verschillende manieren om dit te omzeilen. Hier volgen een aantal suggesties:
- Voer een sortering uit nadat u de downstreambewerking hebt toegepast. Wanneer u bijvoorbeeld rijen groepeert, sorteert u de geneste tabel in elke groep voordat u verdere stappen toepast. Hier volgt een voorbeeld van M-code die deze aanpak demonstreert:
Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}})
- Buffer de gegevens (met behulp van
Table.Buffer
) voordat u de downstreambewerking toepast. In sommige gevallen zorgt deze bewerking ervoor dat de downstreambewerking de gebufferde sorteervolgorde behoudt. - Gebruik classificatie. In plaats van bijvoorbeeld te gebruiken
Table.Distinct
, kunt u rangschikken op basis van de kolommen met de dubbele waarden, rangschikken op basis van een kolom met gelijkbreking (zoalsmodified_date
) en vervolgens filteren om alleen de rang 1 rijen te behouden.
Soms detecteert Power Query het gegevenstype van een kolom onjuist. Dit is het gevolg van het feit dat Power Query gegevenstypen afdingt met alleen de eerste 200 rijen met gegevens. Als de gegevens in de eerste 200 rijen anders zijn dan de gegevens na rij 200, kan Power Query uiteindelijk het verkeerde type ophalen. (Houd er rekening mee dat een onjuist type niet altijd fouten veroorzaakt. Soms zijn de resulterende waarden gewoon onjuist, waardoor het probleem moeilijker te detecteren is.)
Stel dat een kolom met gehele getallen in de eerste 200 rijen (zoals alle nullen) bevat, maar decimale getallen na rij 200 bevat. In dit geval wordt in Power Query het gegevenstype van de kolom afgeleid als geheel getal (Int64.Type). Deze deductie resulteert in de decimale gedeelten van alle niet-gehele getallen die worden afgekapt.
Of stel dat een kolom tekstuele datumwaarden bevat in de eerste 200 rijen en andere soorten tekstwaarden na rij 200. In dit geval wordt in Power Query het gegevenstype van de kolom afgeleid als Datum. Deze deductie resulteert in de niet-datumtekstwaarden die worden behandeld als typeconversiefouten.
Omdat typedetectie werkt op de eerste 200 rijen, maar gegevensprofilering kan worden uitgevoerd voor de hele gegevensset, kunt u overwegen om de functionaliteit Gegevensprofilering te gebruiken om een vroege indicatie te krijgen in de Power Query-editor over fouten (van typedetectie of een willekeurig aantal andere redenen) buiten de bovenste N rijen.
Wanneer u verbinding maakt met verschillende API's, krijgt u mogelijk de volgende waarschuwing:
Data source error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host
Als u deze fout tegenloopt, is dit waarschijnlijk een netwerkprobleem. Over het algemeen zijn de eerste personen die u wilt controleren de eigenaren van de gegevensbron waarmee u verbinding wilt maken. Als ze niet denken dat ze de verbinding sluiten, is het mogelijk dat er iets gaandeweg gebeurt (bijvoorbeeld een proxyserver, tussenliggende routers/gateways, enzovoort).
Of dit nu alleen wordt gereproduceerd met gegevens of alleen grotere gegevensgrootten, het is waarschijnlijk dat er ergens een time-out voor het netwerk op de route is. Als het alleen om grotere gegevens gaat, moeten klanten contact opnemen met de eigenaar van de gegevensbron om te zien of hun API's paging ondersteunen, zodat ze hun aanvragen kunnen splitsen in kleinere segmenten. Als dat niet lukt, moeten alternatieve manieren om gegevens uit de API te extraheren (de aanbevolen procedures voor gegevensbronnen) worden gevolgd.
Per 30 oktober 2020 zijn de volgende suites met coderingsmethoden verwijderd van onze servers.
- "TLS_RSA_WITH_AES_256_GCM_SHA384"
- "TLS_RSA_WITH_AES_128_GCM_SHA256"
- "TLS_RSA_WITH_AES_256_CBC_SHA256"
- "TLS_RSA_WITH_AES_128_CBC_SHA256"
De volgende lijst zijn de ondersteunde coderingssuites:
- "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
- "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
- "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
- "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
- "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"
- "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
- "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
- "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
Suites met coderingsmethoden worden gebruikt om berichten te versleutelen om een netwerkverbinding tussen clients/servers en andere servers te beveiligen. We verwijderen de bovenstaande lijst van suites met coderingsmethoden om te voldoen aan onze huidige beveiligingsprotocollen. Vanaf 1 maart 2021 kunnen klanten alleen onze standaardsuites met coderingsmethoden gebruiken.
Dit zijn de coderingssuites waarmee de server waarmee u verbinding maakt, moet ondersteuning bieden om verbinding te maken vanuit Power Query Online of Power BI.
In Power Query Desktop (Power BI, Excel) hebben we geen controle over uw coderingssuites. Als u verbinding probeert te maken met Power Platform (bijvoorbeeld Power Platform-gegevensstromen) of de Power BI-service, hebt u een van deze coderingssuites nodig die zijn ingeschakeld op uw besturingssysteem. U kunt de Windows-versie upgraden of het Windows TLS-register bijwerken om ervoor te zorgen dat uw servereindpunt een van deze coderingen ondersteunt.
Als u wilt controleren of uw server voldoet aan het beveiligingsprotocol, kunt u een test uitvoeren met behulp van een TLS-coderings- en scannerprogramma. Een voorbeeld hiervan is SSLLABS.
Klanten moeten vóór 1 maart 2021 een upgrade van hun servers uitvoeren. Zie Transport Layer Security (TLS) beheren voor meer informatie over het configureren van TLS Cipher Suite-volgorde.
Een toekomstige versie van Power BI Desktop veroorzaakt een fout in SSL-verbindingen van Desktop wanneer certificaten in de SSL-keten de intrekkingsstatus van certificaten ontbreken. Dit is een wijziging van de huidige status, waarbij het intrekken alleen verbindingsfouten veroorzaakte in het geval dat het certificaat expliciet werd ingetrokken. Andere certificaatproblemen kunnen ongeldige handtekeningen bevatten en het verlopen van certificaten.
Omdat er configuraties zijn waarin de intrekkingsstatus kan worden verwijderd, zoals bij bedrijfsproxyservers, bieden we een andere optie om certificaten te negeren die geen intrekkingsgegevens hebben. Met deze optie kunnen situaties waarin intrekkingsinformatie in bepaalde gevallen wordt verwijderd, maar u de beveiliging niet helemaal wilt verlagen om door te gaan met werken.
Het wordt niet aanbevolen, maar gebruikers kunnen intrekkingscontroles volledig uitschakelen.
Power Query retourneert het bericht 'Evaluatie is geannuleerd' wanneer achtergrondanalyse is uitgeschakeld en de gebruiker schakelt tussen query's of sluit de Power Query-editor terwijl een query bezig is met vernieuwen.
Er zijn veel redenen waarom Power Query mogelijk een fout retourneert dat de sleutel niet overeenkomt met rijen in de tabel. Als deze fout optreedt, kan de Mashup-engine de naam van de tabel niet vinden waarnaar wordt gezocht. Redenen waarom deze fout kan optreden, zijn onder andere:
- De tabelnaam is gewijzigd, bijvoorbeeld in de gegevensbron zelf.
- Het account dat wordt gebruikt voor toegang tot de tabel heeft onvoldoende bevoegdheden om de tabel te lezen.
- Er kunnen meerdere referenties zijn voor één gegevensbron, die niet wordt ondersteund in de Power BI-service bij het gebruik van persoonlijke cloudverbindingen. Deze fout kan bijvoorbeeld optreden wanneer de gegevensbron een cloudgegevensbron is en meerdere accounts worden gebruikt om tegelijkertijd toegang te krijgen tot de gegevensbron met verschillende referenties. Als de gegevensbron on-premises is, moet u de on-premises gegevensgateway gebruiken.
Beperking: Aan een domein gekoppelde vereiste voor gatewaycomputers bij het gebruik van Windows-verificatie
Voor het gebruik van Windows-verificatie met een on-premises gateway moet de gatewaycomputer lid zijn van een domein. Dit geldt voor verbindingen die zijn ingesteld met Windows-verificatie via de gateway*. Windows-accounts die worden gebruikt voor toegang tot een gegevensbron, vereisen mogelijk leestoegang tot de gedeelde onderdelen in de Windows-directory en de gatewayinstallatie.
Als u vanuit Power BI-service verbinding wilt maken met een gegevensbron met behulp van OAuth2, moet de gegevensbron zich in dezelfde tenant bevinden als Power BI-service. Momenteel worden verbindingsscenario's met meerdere tenants niet ondersteund met OAuth2.
De mogelijkheid om een aangepast AD FS-verificatie-eindpunt (Active Directory Federation Services) te gebruiken, wordt niet ondersteund in Power BI-service. Gebruikers kunnen de volgende fout tegenkomen: de tokenservice die door de resource wordt gerapporteerd, wordt niet vertrouwd.
Het gebruik van gastaccounts van een tenant om verbinding te maken met gegevens met behulp van Power Query-connectors wordt momenteel niet ondersteund.
Stack-overloopfouten kunnen worden veroorzaakt door een fout in uw M-code. De volgende functie produceert bijvoorbeeld een stack-overloop, omdat deze herhaaldelijk terugroept naar zichzelf zonder een soort eindvoorwaarde. Een functie die zichzelf als deze aanroept, wordt een 'recursieve' functie genoemd.
let f = (x) => @f(x + 1) in f(0)
Hier volgen enkele veelvoorkomende manieren om een stack-overloop in uw M-code op te lossen.
- Zorg ervoor dat uw recursieve functies daadwerkelijk worden beëindigd wanneer de verwachte eindvoorwaarde is bereikt.
- Vervang recursie door iteratie (bijvoorbeeld door functies zoals List.Transform, List.Generate of List.Accumulate te gebruiken).
Fouten met onvoldoende geheugen (of OOM's) kunnen worden veroorzaakt door te veel geheugenintensieve bewerkingen voor zeer grote tabellen. De volgende M-code produceert bijvoorbeeld een OOM, omdat er tegelijkertijd wordt geprobeerd om miljarden rijen in het geheugen te laden.
Table.Buffer(Table.FromList({1..1000000000}, Splitter.SplitByNothing()))
Om geheugenfouten op te lossen, optimaliseert u geheugenintensieve bewerkingen, zoals sorteringen, joins, groepering en verschillen door ervoor te zorgen dat ze naar de bron worden gevouwen of door ze waar mogelijk helemaal te verwijderen. Sorteringen zijn bijvoorbeeld vaak onnodig.
Soms start u een gegevensstroomvernieuwing, maar nadat u deze hebt gestart, beseft u dat u nog één ding wilt wijzigen voordat u uw gegevens vernieuwt. In dat geval moet u wachten totdat het vernieuwen is voltooid. Een vernieuwing halverwege stoppen omdat het proces al bezig is met het ophalen van de gegevens en het bijwerken van de tabellen in uw werkruimte of omgeving wordt momenteel niet ondersteund.
We zijn van plan om in de toekomst ondersteuning toe te voegen voor het annuleren van een gegevensstroomvernieuwing.