Běžné problémy
Můžete předpokládat, že pokud seřadíte data, všechny podřízené operace zachovávají pořadí řazení.
Pokud například seřadíte tabulku prodejů tak, aby se jako první zobrazily největší prodej v obchodě, můžete očekávat, že operace "Odebrat duplicity" vrátí pouze nejvyšší prodej pro každou prodejnu. A tato operace může ve skutečnosti fungovat. Toto chování ale není zaručené.
Vzhledem ke způsobu, jakým Power Query optimalizuje určité operace, včetně jejich přeskočení nebo snižování zátěže do zdrojů dat (které můžou mít vlastní jedinečné chování řazení), není zaručeno, že se pořadí řazení zachová prostřednictvím agregací (například Table.Group
), sloučení (například Table.NestedJoin
) nebo duplicitního odebrání (například Table.Distinct
).
Existuje několik způsobů, jak to obejít. Zde je několik návrhů:
- Po použití podřízené operace proveďte řazení. Když například seskupíte řádky, před použitím dalších kroků seřadíte vnořenou tabulku v každé skupině. Tady je ukázkový kód M, který ukazuje tento přístup:
Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}})
- Před použitím podřízené operace do vyrovnávací paměti data (pomocí
Table.Buffer
) V některých případech tato operace způsobí, že podřízená operace zachová pořadí řazení ve vyrovnávací paměti. - Používejte řazení. Místo použití
Table.Distinct
můžete například pořadí podle sloupců obsahujících duplicitní hodnoty uspořádat na základě sloupce tie-breaker (napříkladmodified_date
) a potom filtrovat tak, aby se zachovaly pouze řádky pořadí 1.
Power Query někdy může nesprávně rozpoznat datový typ sloupce. Důvodem je fakt, že Power Query odvodí datové typy pomocí pouze prvních 200 řádků dat. Pokud se data v prvních 200 řádcích nějak liší od dat za řádkem 200, může Power Query nakonec vybrat nesprávný typ. (Mějte na paměti, že nesprávný typ ne vždy způsobí chyby. Někdy jsou výsledné hodnoty jednoduše nesprávné, což znesnadňuje zjištění problému.)
Představte si například sloupec, který obsahuje celá čísla v prvních 200 řádcích (například ve všech nulách), ale obsahuje desetinná čísla za řádkem 200. V tomto případě Power Query odvodí datový typ sloupce jako Celé číslo (Int64.Type). Výsledkem této odvozování jsou desetinné části všech neintegerních čísel zkrácených.
Nebo si představte sloupec, který obsahuje textové hodnoty kalendářních dat v prvních 200 řádcích a další druhy textových hodnot za řádkem 200. V tomto případě Power Query odvodí datový typ sloupce datem. Výsledkem tohoto odvozování jsou textové hodnoty, které nejsou kalendářními daty, jako chyby převodu typů.
Vzhledem k tomu, že detekce typů funguje na prvních 200 řádcích, ale profilace dat může pracovat s celou sadou dat, můžete zvážit použití funkce profilace dat, abyste získali počáteční indikaci v Editor Power Query o chybách (z detekce typů nebo z jakéhokoliv jiného počtu důvodů) nad horními N řádky.
Při připojování k různým rozhraním API se může zobrazit následující upozornění:
Data source error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host
Pokud narazíte na tuto chybu, pravděpodobně se jedná o problém se sítí. Obecně platí, že první uživatelé, se kterými se chcete zkontrolovat, jsou vlastníky zdroje dat, ke kterému se pokoušíte připojit. Pokud si nemyslí, že připojení zavírají, je možné, že je to něco tak, že (například proxy server, zprostředkující směrovače nebo brány atd.).
Ať už se jedná jenom o data nebo jenom větší velikost dat, je pravděpodobné, že někde na trase dojde k vypršení časového limitu sítě. Pokud se jedná pouze o větší data, měli by se zákazníci obrátit na vlastníka zdroje dat a zjistit, jestli jejich rozhraní API podporují stránkování, aby mohli žádosti rozdělit na menší bloky dat. Pokud se to nepodaří, měli byste dodržovat alternativní způsoby extrakce dat z rozhraní API (podle osvědčených postupů pro zdroje dat).
S účinností od 30. října 2020 jsou na našich serverech zneplatněny následující šifrovací sady.
- "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"
Následující seznam obsahuje podporované šifrovací sady:
- "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"
Šifrovací sady se používají k šifrování zpráv k zabezpečení síťového připojení mezi klienty/servery a jinými servery. Odstraňujeme výše uvedený seznam šifrovacích sad, abychom vyhověli našim současným bezpečnostním protokolům. Od 1. března 2021 mohou zákazníci používat pouze naše standardní šifrovací sady.
Toto jsou šifrovací sady serveru, ke kterému se připojujete, musí podporovat připojení z Power Query Online nebo Power BI.
V Power Query Desktopu (Power BI, Excel) neřídíme vaše šifrovací sady. Pokud se pokoušíte připojit k Power Platform (například tokům dat Power Platform) nebo službě Power BI, potřebujete jednu z těchto šifrovacích sad povolenou ve vašem operačním systému. Můžete buď upgradovat verze pro Windows nebo aktualizovat Registr TLS systému Windows, abyste měli jistotu, že váš serverový koncový bod podporuje jednu z těchto šifer.
Pokud chcete ověřit, že váš server splňuje protokol zabezpečení, můžete test provést pomocí nástroje šifry a skeneru PROTOKOLU TLS. Jedním z příkladů může být SSLLABS.
Zákazníci musí upgradovat své servery do 1. března 2021. Další informace o konfiguraci objednávky šifrovací sady TLS najdete v části Správa protokolu TLS (Transport Layer Security).
Nadcházející verze Power BI Desktopu způsobí selhání připojení SSL z Desktopu, když v řetězu SSL chybí stav odvolání certifikátu. Jedná se o změnu z aktuálního stavu, kdy odvolání způsobilo pouze selhání připojení v případě, kdy byl certifikát explicitně odvolán. Jiné problémy s certifikáty můžou zahrnovat neplatné podpisy a vypršení platnosti certifikátu.
Vzhledem k tomu, že existují konfigurace, ve kterých se může zrušit stav odvolání, například u podnikových proxy serverů, poskytneme další možnost ignorovat certifikáty, které nemají informace o odvolání. Tato možnost umožňuje situace, kdy jsou informace o odvolání v určitých případech odvolané, ale nechcete úplně snížit zabezpečení, pokračovat v práci.
Nedoporučuje se, ale uživatelé můžou dál používat kontroly odvolání úplně.
Power Query vrátí zprávu Vyhodnocení bylo zrušeno, když je analýza na pozadí zakázaná a uživatel přepne mezi dotazy nebo zavře Editor Power Query, když se dotaz právě aktualizuje.
Power Query může z mnoha důvodů vrátit chybu, že klíč neodpovídá žádným řádkům v tabulce. Pokud k této chybě dojde, mashupový modul nemůže najít název tabulky, který hledá. Mezi důvody, proč k této chybě může dojít, patří:
- Název tabulky byl změněn, například v samotném zdroji dat.
- Účet použitý pro přístup k tabulce nemá dostatečná oprávnění ke čtení tabulky.
- Pro jeden zdroj dat může existovat více přihlašovacích údajů, které se ve službě Power BI nepodporují při použití osobních cloudových připojení. K této chybě může dojít například v případě, že je zdrojem dat cloudový zdroj dat a k přístupu ke zdroji dat současně s různými přihlašovacími údaji se používá více účtů. Pokud je zdroj dat místní, budete muset použít místní bránu dat.
Použití ověřování systému Windows s místní bránou vyžaduje, aby byl počítač brány připojený k doméně. To platí pro všechna připojení, která jsou nastavená pomocí ověřování systému Windows prostřednictvím brány*. Účty Systému Windows, které se používají pro přístup ke zdroji dat, můžou vyžadovat přístup pro čtení ke sdíleným komponentám v adresáři Windows a instalaci brány.
Pokud se chcete připojit ke zdroji dat z služba Power BI pomocí OAuth2, musí být zdroj dat ve stejném tenantovi jako služba Power BI. V současné době se u OAuth2 nepodporují scénáře připojení s více tenanty.
Možnost používat vlastní koncový bod ověřování Active Directory Federation Services (AD FS) (AD FS) není v služba Power BI podporována. Uživatelům se může zobrazit následující chyba: Služba tokenů hlášená prostředkem není důvěryhodná.
Použití účtů hostů tenanta pro připojení k datům pomocí konektorů Power Query se v současné době nepodporuje.
Chyby přetečení zásobníku můžou být způsobené chybou v kódu M. Například následující funkce vytvoří přetečení zásobníku, protože opakovaně volá zpět do sebe bez jakéhokoli druhu koncové podmínky. Funkce, která volá sama sebe jako tato, se označuje jako "rekurzivní" funkce.
let f = (x) => @f(x + 1) in f(0)
Tady je několik běžných způsobů řešení přetečení zásobníku v kódu M.
- Ujistěte se, že se rekurzivní funkce skutečně ukončí při dosažení očekávané koncové podmínky.
- Nahraďte rekurze iterací (například pomocí funkcí, jako jsou List.Transform, List.Generate nebo List.Accumulate).
Chyby typu Nedostatek paměti (nebo OOM) můžou být způsobené příliš mnoha operacemi náročnými na paměť u velmi velkých tabulek. Například následující kód M vytvoří OOM, protože se pokusí načíst miliardy řádků do paměti najednou.
Table.Buffer(Table.FromList({1..1000000000}, Splitter.SplitByNothing()))
Pokud chcete vyřešit chyby způsobené nedostatkem paměti, optimalizujte operace náročné na paměť, jako jsou řazení, spojení, seskupování a jedinečné položky tím, že zajistíte, že se přeloží do zdroje nebo je úplně odeberete, pokud je to možné. Řazení je například často zbytečné.
Někdy spustíte aktualizaci toku dat, ale po jejím spuštění zjistíte, že jste před aktualizací dat chtěli ještě jednu věc změnit. V takovém případě musíte počkat, až se aktualizace dokončí. Zastavení aktualizace uprostřed, protože proces už pracuje na získání dat a aktualizaci tabulek v pracovním prostoru nebo prostředí, se v současné době nepodporuje.
Plánujeme přidat podporu pro zrušení aktualizace toku dat v budoucnu.