Gyakori problémák

Power Query

Rendezés megőrzése

Feltételezheti, hogy az adatok rendezésekor az alárendelt műveletek megőrzik a rendezési sorrendet.

Ha például úgy rendez egy értékesítési táblát, hogy az egyes áruházak legnagyobb eladása jelenjen meg először, előfordulhat, hogy az "Ismétlődések eltávolítása" művelet csak az egyes áruházak felső értékesítését adja vissza. És ez a művelet úgy tűnhet, hogy működik. Ez a viselkedés azonban nem garantált.

Mivel a Power Query optimalizál bizonyos műveleteket, például kihagyja őket, vagy ki van osztva az adatforrásokra (amelyek saját egyedi rendezési viselkedéssel rendelkezhetnek), a rendezési sorrend nem garantáltan megmarad az összesítések (például Table.Group), az egyesítések (például Table.NestedJoin) vagy a duplikált eltávolítás (például Table.Distinct).

Ennek a megoldásnak számos módja van. Íme néhány javaslat:

• Végezze el a rendezést az alsóbb rétegbeli művelet alkalmazása után . Sorok csoportosításakor például a további lépések végrehajtása előtt rendezze a beágyazott táblázatot az egyes csoportokban. Íme néhány M-mintakód, amely bemutatja ezt a megközelítést: Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}})
• Pufferelje az adatokat (használva Table.Buffer) az alsóbb rétegbeli művelet alkalmazása előtt. Bizonyos esetekben ez a művelet miatt az alsóbb rétegbeli művelet megőrzi a pufferelt rendezési sorrendet.
• Rangsorolás használata. Például, a Table.Distinct használata helyett sorba rendezhet azokat az oszlopokat, amelyek duplikált értékeket tartalmaznak, a tie-breaker oszlop (mint például modified_date) alapján rangsorolhatja őket, majd szűrhet, hogy csak a rang 1-es sorokat tartsa meg.

Adattípus-következtetés

Előfordulhat, hogy a Power Query helytelenül észleli egy oszlop adattípusát. Ennek az az oka, hogy a Power Query csak az első 200 adatsor használatával következtet adattípusokra. Ha az első 200 sor adatai valahogy eltérnek a 200. sor utáni adatoktól, a Power Query végül nem a megfelelő típust választja. (Vegye figyelembe, hogy a helytelen típus nem mindig eredményez hibákat. Néha az eredményül kapott értékek egyszerűen helytelenek, ami megnehezíti a probléma észlelését.)

Képzeljen el például egy olyan oszlopot, amely az első 200 sorban egész számokat tartalmaz (például az összes nullát), de a 200. sor után decimális számokat tartalmaz. Ebben az esetben a Power Query megállapítja, hogy az oszlop adattípusa Egész szám (Int64.Type). Ez a következtetés azt eredményezi, hogy a nem egész számok tizedesrészei csonkolva lesznek.

Vagy képzeljen el egy oszlopot, amely szöveges dátumértékeket tartalmaz az első 200 sorban, és más típusú szöveges értékeket a 200. sor után. Ebben az esetben a Power Query a Dátum oszlop adattípusára következtet. Ez a következtetés azt eredményezi, hogy a nem dátum szöveges értékek típuskonvertálási hibákként lesznek kezelve.

Mivel a típusészlelés az első 200 sorban működik, de az adatprofilozás a teljes adatkészleten keresztül működik, érdemes lehet az Adatprofilozás funkcióval korai jelzést kapni a Lekérdezésszerkesztőben a hibákról (a típusészleléstől vagy bármilyen más októl) a felső N sorokon túl.

A távoli szerver által kényszerítetten bezárt kapcsolatok

Amikor különböző API-khoz csatlakozik, a következő figyelmeztetést kaphatja:

Data source error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

Ha ezt a hibát tapasztalja, az valószínűleg hálózati probléma. Általában az első személy, akivel kapcsolatba kíván lépni, annak az adatforrásnak a tulajdonosai, amelyhez csatlakozni próbál. Ha nem hiszik, hogy ők zárják be a kapcsolatot, akkor lehetséges, hogy valami az út mentén van (például proxykiszolgáló, köztes útválasztók/átjárók stb.).

Függetlenül attól, hogy ez csak bármilyen adattal vagy csak nagyobb adatmérettel reprodukálható, valószínű, hogy hálózati időtúllépés van valahol az útvonalon. Ha csak nagyobb adatokkal van, az ügyfeleknek konzultálniuk kell az adatforrás tulajdonosával, hogy az API-k támogatják-e a lapozást, hogy a kéréseiket kisebb adattömbökre oszthassák. Ennek hiányában alternatív módszereket kell követni az adatok API-ból való kinyerésére (az adatforrások ajánlott eljárásait követve).

A TLS RSA titkosítócsomagok elavultak

2020. október 30-ától a következő titkosítócsomagok elavultak a szervereinken.

• "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"

Az alábbi lista a támogatott titkosítási csomagokat tartalmazza:

• 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"

A titkosítócsomagok az üzenetek titkosítására szolgál az ügyfelek/kiszolgálók és más kiszolgálók közötti hálózati kapcsolatok biztonságossá tétele érdekében. Eltávolítjuk a titkosítócsomagokat, hogy megfeleljünk a jelenlegi biztonsági protokolljainknak. 2021. március 1-jétől kezdődően az ügyfelek csak a standard titkosítócsomagokat használhatják.

Ezek azok a titkosítási csomagok, amelyekhez a kiszolgálónak csatlakoznia kell a Power Query Online-ból vagy a Power BI-ból való csatlakozáshoz.

A Power Query Desktopban (Power BI, Excel) nem szabályozzuk a titkosítási csomagokat. Ha a Power Platformhoz (például a Power Platform adatfolyamaihoz) vagy a Power BI szolgáltatáshoz próbál csatlakozni, az operációs rendszeren engedélyeznie kell a titkosítási csomagok egyikét. Frissítheti a Windows verziót, vagy frissítheti a Windows TLS regisztrációs adatbázisát, hogy meggyőződjön arról, hogy a kiszolgálói végpont biztosan támogatja-e ezen titkosítók valamelyikét.

Annak ellenőrzéséhez, hogy a kiszolgáló megfelel-e a biztonsági protokollnak, TLS-titkosítási és képolvasó eszközzel végezhet tesztet. Ilyen lehet például az SSLLABS.

Az ügyfeleknek 2021. március 1-je előtt kell frissíteniük a kiszolgálókat. A TLS titkosítócsomag-rendelés konfigurálásával kapcsolatos további információkért lásd: Transport Layer Security (TLS) kezelése.

Tanúsítvány visszavonása

A Power BI Desktop következő verziója SSL-kapcsolatok meghibásodását okozza a Power BI Desktopban, ha az SSL-láncban lévő tanúsítványokból hiányzik a tanúsítványok visszavonási állapota. Ez egy változás az aktuális állapothoz, ahol a visszavonás csak akkor okozott csatlakozási hibát, ha a tanúsítványt kifejezetten visszavonták. Más tanúsítványproblémák közé tartozhatnak az érvénytelen aláírások és a tanúsítvány lejárata.

Mivel vannak olyan konfigurációk, amelyekben a visszavonási állapot megszüntethető, például a vállalati proxykiszolgálók esetében, egy másik lehetőséget biztosítunk a visszavonási adatokkal nem rendelkező tanúsítványok figyelmen kívül hagyására. Ez a beállítás lehetővé teszi, hogy a visszavonási adatok bizonyos esetekben megszűnjenek, de nem szeretné teljes mértékben csökkenteni a biztonságot, hogy továbbra is működjön.

Ez nem ajánlott, de a felhasználók továbbra is teljes mértékben kikapcsolhatják a visszavonási ellenőrzéseket.

Hiba: A kiértékelés megszakadt

A Power Query a "Kiértékelés megszakítva" üzenetet adja vissza, ha a háttérelemzés le van tiltva, és a felhasználó vált a lekérdezések között, vagy bezárja a Lekérdezésszerkesztőt, miközben a lekérdezés frissítés alatt áll.

Hiba: A kulcs nem egyezett a táblázat egyik sorával sem

A Power Query számos oka lehet annak, hogy olyan hibát ad vissza, amely miatt a kulcs nem felelt meg a tábla egyik sorának sem. Ha ez a hiba történik, az összefésítési motor nem találja a keresett táblanevet. A hiba okai a következők lehetnek:

• A tábla neve megváltozott, például magában az adatforrásban.
• A táblához való hozzáféréshez használt fiók nem rendelkezik elegendő jogosultsággal a tábla olvasásához.
• Egyetlen adatforráshoz több hitelesítő adat is lehet, amely a Személyes felhőkapcsolatok használata esetén nem támogatott a Power BI szolgáltatásban. Ez a hiba például akkor fordulhat elő, ha az adatforrás egy felhőbeli adatforrás, és több fiókot használnak az adatforrás egyidejű eléréséhez különböző hitelesítő adatokkal. Ha az adatforrás helyszíni, akkor a helyszíni adatátjárót kell használnia.

Korlátozás: Az átjárógépek tartományhoz való csatlakoztatásának konfigurációs követelménye Windows-hitelesítés használatakor.

A Windows-hitelesítés helyszíni átjáróval való használatához tartományhoz kell csatlakoznia az átjárógépnek. Ez minden olyan kapcsolatra vonatkozik, amely a "Windows-hitelesítés az átjárón keresztül* beállítással van beállítva. Az adatforrás eléréséhez használt Windows-fiókok olvasási hozzáférést igényelhetnek a Megosztott összetevőkhöz a Windows címtárban és az átjáró telepítésében.

Korlátozás: A bérlők közötti OAuth2-frissítés nem támogatott a Power BI szolgáltatásban

Ha az OAuth2 használatával szeretne csatlakozni egy adatforráshoz a Power BI szolgáltatásból, az adatforrásnak ugyanabban a bérlőben kell lennie, mint a Power BI szolgáltatásnak. Az OAuth2 jelenleg nem támogatja a több-bérlős kapcsolati forgatókönyveket.

Korlátozás: Az egyéni AD FS-hitelesítési végpont nem támogatott a Power BI szolgáltatásban

Az egyéni Active Directory összevonási szolgáltatások (AD FS) hitelesítési végpontjának használata nem támogatott a Power BI szolgáltatásban. A felhasználók a következő hibát tapasztalhatják: Az erőforrás által jelentett jogkivonat-szolgáltatás nem megbízható.

Korlátozás: A vendégfiókok nem támogatottak

Jelenleg nem támogatott, ha egy bérlő vendégfiókjait használja az adatokhoz való csatlakozáshoz Power Query-összekötőkkel.

Expression.Error: A kiértékelés verem túlcsordulást eredményezett, és nem folytatható

A verem túlcsordulási hibákat az M-kód hibái okozhatják. Az alábbi függvény például egy verem túlcsordulását eredményezi, mert a függvény ismételten visszahívja magát mindenféle végfeltétel nélkül. A magát így hívogató függvényt "rekurzív" függvénynek nevezzük.

let f = (x) => @f(x + 1) in f(0)

Az alábbiakban néhány gyakori módszert talál M-kódok verem túlcsordulásának megoldására.

• Győződjön meg arról, hogy a rekurzív függvények ténylegesen leállnak a várt végfeltétel elérésekor.
• Cserélje le a rekurziót iterációra (például olyan függvények használatával, mint a List.Transform, a List.Generate vagy a List.Accumulate).

Expression.Error: A kiértékelési memória elfogyt, és nem folytatható

A "Nincs elég memória" hibákat (vagy OOM-ok) okozhatja, ha túl sok memóriaigényes műveletet hajtanak végre nagyon nagy táblákon. Az alábbi M-kód például egy OOM-ot hoz létre, mert egyszerre egy milliárd sort próbál betölteni a memóriába.

Table.Buffer(Table.FromList({1..1000000000}, Splitter.SplitByNothing()))

A memóriahibák megoldásához optimalizálja a memóriaigényes műveleteket, mint például a rendezéseket, az illesztéseket, a csoportosítást és az egyedi műveleteket, azáltal, hogy biztosítja, ezek a forrásra irányulnak, vagy ha lehetséges, teljesen eltávolítja őket. A rendezés például gyakran szükségtelen.

A Power Query Online nem tud nyilvános végponton keresztül csatlakozni, ha egy privát végpont konfigurálva van egy tárolóhoz

Ha egy tárfiókhoz tartozó privát végpont van konfigurálva, a Power Query Online mindig feloldja a privát kapcsolat címét, és nem tud csatlakozni a nyilvános interneten keresztül – még akkor sem, ha a nyilvános hozzáférés "Engedélyezett" értékre van állítva a privát végpont konfigurációjában.

Ez a viselkedés azért fordul elő, mert a privát végpont elsőbbséget élvez a nyilvános kapcsolattal szemben. Ennek eredményeképpen az átjáró nélküli kapcsolódási kísérletek sikertelenek lesznek.

Bizonyos speciális karakterműveletek végrehajtásakor megjelenő hibaüzenet ablak

Ha koreai IME-billentyűzetet használ a Power Queryben, hibaablak jelenhet meg, amikor bizonyos speciális karaktereket ad meg a speciális szerkesztőben, az Egyéni oszlop párbeszédpanelen vagy a szerkesztősávon.

Ez a probléma hatással van a Power BI Desktopban és az Excelben található Power Query-szerkesztőre. Ez nem befolyásolja a Power Query Online-t (adatfolyamokat).

A probléma megoldásához tiltsa le az M Intellisense-t a Power Query-szerkesztő beállításai között.

Dataflows

Adatfolyam frissítésének megszakítása

Néha elindít egy adatfolyam-frissítést, de az indítás után rájön, hogy még egy dolgot módosítani szeretne az adatok frissítése előtt. Ebben az esetben meg kell várnia, amíg a frissítés befejeződik. A frissítés félúton történő leállítása, mivel a folyamat már dolgozik az adatok lekérésén, és a munkaterületen vagy a környezetben lévő táblák frissítése jelenleg nem támogatott.

Tervezzük, hogy a jövőben támogatást adunk az adatfolyamok frissítésének megszakításához.