Megosztás a következőn keresztül:

Gyakori problémák

  • Cikk

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. A használat Table.Distincthelyett például a duplikált értékeket tartalmazó oszlop(ok) szerint rendezheti, egy tie-breaker oszlop alapján rangsorolhat (például modified_date), majd szűrhet, hogy csak az 1. sor legyen megtartva.

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 az oszlop adattípusát Egész szám (Int64.Type) értékre követi. 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 működik, érdemes lehet az Adatprofilozás funkcióval korai jelzést kapni a Lekérdezésszerkesztő a hibákról (a típusészlelésből vagy bármilyen más okból) a felső N soron túl.

A távoli gazdagép á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-beállításjegyzéket , hogy a kiszolgálóvégpont biztosan támogatja-e a titkosítások egyiké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 megrendelésének konfigurálásával kapcsolatos további tudnivalók: Transport Layer Security (TLS) kezelése.

Tanúsítvány visszavonása

A Power BI Desktop közelgő verziója ssl-kapcsolatok meghibásodását okozza az Asztalról, ha az SSL-láncban lévő tanúsítványokból hiányzik a visszavont tanúsítványok á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ő, 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 csatlakoztatott követelménye Windows-hitelesítés használata esetén

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ás

Ha Power BI szolgáltatás OAuth2 használatával szeretne adatforráshoz csatlakozni, az adatforrásnak ugyanabban a bérlőben kell lennie, mint Power BI szolgáltatás. 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ás

Az egyéni Active Directory összevonási szolgáltatások (AD FS) (AD FS) hitelesítési végpontok használata nem támogatott a Power BI szolgáltatás. 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áit az M-kód hibája okozhatja. 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 a verem túlcsordulásának feloldására az M-kódban.

  • 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 "Memóriakihasználtság" hibák (vagy OOM-ok) oka lehet, ha túl sok memóriaigényes műveletet végez 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, például a rendezéseket, az illesztéseket, a csoportosítást és a különböző műveleteket úgy, hogy biztosítják, hogy a forráshoz hajtsanak, vagy ha lehetséges, teljesen eltávolítsák őket. A rendezés például gyakran szükségtelen.

Adatfolyamok

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.