Power Query – 10 najczęstszych problemów z danymi i sposoby ich rozwiązania

Wprowadzenie: dlaczego pojawiają się problemy z danymi w Power Query?

Zapytanie działa przy pierwszym imporcie, ale po odświeżeniu zgłasza błąd albo zwraca inne wyniki niż oczekiwane. To typowy scenariusz pracy z Power Query: kroki przygotowane na podstawie jednego zestawu danych trafiają później na dane, które nie spełniają tych samych założeń. Przyczyną może być zmiana w pliku źródłowym, inny sposób zapisu wartości lub niejednolite zasady wprowadzania informacji.

Power Query służy do pobierania, przekształcania i łączenia danych — między innymi w Excelu i Power BI. Sprawdza się szczególnie przy cyklicznym przygotowywaniu raportów, scalaniu plików i porządkowaniu eksportów z różnych systemów. W odróżnieniu od ręcznej edycji arkusza zapisuje kolejne operacje i wykonuje je ponownie podczas odświeżania. Oszczędza to pracę, ale oznacza również, że raz przyjęte założenie będzie stosowane do następnych zestawów danych, nawet jeśli przestanie do nich pasować.

Źródła trudności warto rozdzielić na trzy obszary: dane wejściowe, sposób ich interpretacji oraz logikę przekształceń. W pierwszym przypadku problem istnieje już w źródle. W drugim dane mogą być poprawne, lecz Power Query odczytuje je inaczej, niż oczekuje użytkownik. W trzecim niepożądany wynik powstaje wskutek wykonanych operacji lub ich kolejności. To rozróżnienie pomaga ustalić, czy poprawy wymaga źródło, ustawienie importu czy samo zapytanie.

Brak komunikatu o błędzie nie gwarantuje poprawnego wyniku. Zapytanie może zakończyć się powodzeniem, a mimo to pominąć potrzebne rekordy lub zmienić znaczenie informacji. Dlatego diagnozę najlepiej zacząć od porównania oczekiwanego rezultatu z wynikiem i wskazania pierwszego kroku, w którym pojawia się rozbieżność. Warto też sprawdzić, czy dotyczy ona całego zbioru, pojedynczego pliku czy tylko nowych danych. Takie podejście zawęża obszar poszukiwań i pomaga usunąć przyczynę problemu, zamiast jedynie ukrywać jego objawy.

Błędy typów danych: złe typy, konwersje i utrata wartości

Kolumna zawierająca cyfry nie zawsze powinna mieć typ liczbowy. Numer zamówienia może być identyfikatorem, a kwota zapisana jako tekst nie będzie gotowa do obliczeń. W Power Query typ danych określa sposób interpretacji i przetwarzania wartości, a nie tylko ich wygląd. Niewłaściwy wybór może zablokować obliczenia, wywołać błędy konwersji lub zmienić dane bez wyraźnego ostrzeżenia. Podczas szkoleń Cognity pytania o dobór typów danych wracają regularnie — dlatego omawiamy ten temat również na blogu.

Niewłaściwy typ przypisany automatycznie

Przy imporcie z nieustrukturyzowanych źródeł, takich jak pliki CSV, Power Query może automatycznie wykryć typy i dodać krok „Zmieniono typ”. To wygodne, ale rozpoznanie na podstawie początkowych wierszy nie gwarantuje poprawnej interpretacji całej kolumny. Jeśli pierwsze wartości wyglądają jak liczby, a dalej pojawia się identyfikator zawierający litery, automatyczna konwersja może zakończyć się błędem.

Sprawdź ikonę typu przy nazwie kolumny oraz ustawienia kroku „Zmieniono typ”. Typ dobieraj do znaczenia danych:

• Tekst — dla kodów, numerów dokumentów i identyfikatorów, na których nie wykonujesz działań matematycznych.
• Liczba całkowita — dla liczby sztuk i innych wielkości, które rzeczywiście nie mają części ułamkowej.
• Liczba dziesiętna — dla pomiarów i wartości ułamkowych; przy wymaganej dokładności uwzględnij ograniczenia reprezentacji zmiennoprzecinkowej.
• Stała liczba dziesiętna — gdy potrzebna jest dokładna reprezentacja wartości z maksymalnie czterema miejscami po przecinku, na przykład w określonych obliczeniach finansowych.
• Data lub data/godzina — zależnie od tego, czy informacja o godzinie jest potrzebna w analizie.

Błędy podczas konwersji

Wartość „Error” po zmianie typu oznacza, że konkretnego wpisu nie udało się przekształcić zgodnie z wybraną regułą. Przykładowo tekst „do ustalenia” nie może zostać bezpośrednio zamieniony na liczbę. Kliknij komórkę z błędem i odczytaj jego szczegóły, a następnie wróć do kroku poprzedzającego konwersję, aby sprawdzić pierwotną wartość.

Nie zastępuj wszystkich błędów zerem ani nie usuwaj takich wierszy bez sprawdzenia przyczyny. Zero jest konkretną wartością i może zmienić średnie lub inne wyniki analizy. Najpierw ustal, czy błędnie wybrano typ kolumny, czy pojedynczy wpis wymaga osobnej reguły obsługi. Pomocna jest funkcja zachowania wierszy z błędami, która pozwala wyodrębnić problematyczne rekordy do kontroli.

Utrata wartości bez komunikatu o błędzie

Nie każda niepoprawna konwersja wywołuje błąd. Zamiana identyfikatora „00127” na liczbę usuwa zera wiodące. Przekształcenie daty z godziną w samą datę odrzuca czas, a przejście na liczbę całkowitą może zaokrąglić część ułamkową. Szczególnej ostrożności wymagają też długie identyfikatory: typ zmiennoprzecinkowy nie zapewnia dokładnego zapisu dowolnie długiego ciągu cyfr.

Jeżeli konwersja usunęła istotne informacje, popraw lub usuń krok, który ją wykonał. Późniejsza zmiana liczby z powrotem na tekst nie przywróci utraconych zer ani zmienionych cyfr. Przed zatwierdzeniem transformacji porównaj wartości przed zmianą i po niej — zwłaszcza identyfikatory, ułamki oraz znaczniki czasu.

Lokalizacja i formaty liczb oraz dat: przecinki, kropki i niejednolite zapisy

Wartość 1,234 może oznaczać liczbę z częścią ułamkową albo tysiąc dwieście trzydzieści cztery. Podobnie zapis 04/05/2025 nie rozstrzyga, czy chodzi o 4 maja, czy 5 kwietnia. Power Query interpretuje takie dane według ustawień regionalnych użytych podczas konwersji. Jeśli nie odpowiadają one konwencji źródła, wynik może być błędny — nawet wtedy, gdy w podglądzie nie pojawia się żaden komunikat o błędzie.

Separatory liczb: znaczenie zależy od lokalizacji

W polskim zapisie przecinek oddziela część dziesiętną, natomiast w zapisie amerykańskim tę funkcję pełni kropka. Przecinek może tam z kolei rozdzielać grupy tysięcy. Przy imporcie liczb zapisanych jako tekst trzeba więc ustalić nie tylko separator dziesiętny, lecz także sposób grupowania cyfr.

Nie zamieniaj automatycznie wszystkich kropek na przecinki. Wartość 1,234.56 po takiej operacji zmieni się w 1,234,56, czyli zapis, który nadal nie nadaje się do prawidłowej konwersji. Przy jednolitej konwencji źródła właściwym rozwiązaniem jest wskazanie lokalizacji, a nie ręczne przestawianie separatorów.

Jak zastosować właściwe ustawienia regionalne

W Edytorze Power Query kliknij nagłówek kolumny prawym przyciskiem myszy i wybierz Zmień typ → Użyj ustawień regionalnych. Następnie wskaż docelowy typ, na przykład liczbę dziesiętną lub datę, oraz lokalizację odpowiadającą zapisowi w źródle. Dla dat w kolejności miesiąc/dzień/rok będzie to zwykle Angielski (Stany Zjednoczone), a dla dzień/miesiąc/rok — odpowiednia lokalizacja stosująca tę kolejność.

Ważny jest moment wykonania tej operacji. Ustawienia regionalne należy zastosować do oryginalnych wartości tekstowych. Jeśli wcześniejszy krok „Zmieniono typ” zdążył już nieprawidłowo odczytać liczbę lub datę, usuń go albo popraw. Dodanie kolejnej konwersji nie odtworzy pierwotnego znaczenia danych.

Sprawdź też kilka wartości kontrolnych, najlepiej takich, których znaczenie znasz ze źródła. Sam brak błędów nie wystarcza: obie interpretacje daty 04/05/2025 są technicznie poprawne, ale tylko jedna odpowiada rzeczywistemu zdarzeniu.

Niejednolite daty: kiedy jedna lokalizacja nie wystarczy

Jeżeli część wierszy pochodzi ze źródła polskiego, a część z amerykańskiego, ustawienie jednej lokalizacji dla całej kolumny nie rozwiąże problemu. Najbezpieczniej interpretować daty osobno dla każdego źródła, zanim dane zostaną połączone. Gdy są już w jednej tabeli, regułę konwersji należy oprzeć na wiarygodnej informacji o pochodzeniu lub udokumentowanym formacie.

Nie warto zgadywać kolejności dnia i miesiąca na podstawie samego separatora. Ukośnik występuje zarówno w zapisach brytyjskich, jak i amerykańskich. Bez dodatkowego kontekstu nie da się jednoznacznie rozstrzygnąć wartości takich jak 04/05/2025; wymagają one wyjaśnienia u dostawcy danych.

Na koniec rozdziel dwie kwestie: interpretację wartości i jej wygląd w raporcie. Lokalizacja podczas konwersji decyduje o tym, jaką liczbę lub datę otrzymasz. Format komórki w Excelu czy format pola w Power BI określa sposób jej wyświetlania — nie naprawia błędnego odczytu.

Struktura tabeli: nagłówki, puste wiersze, zbędne kolumny i przesunięcia danych

Arkusz przygotowany do czytania przez człowieka nie zawsze nadaje się do bezpośredniego przetwarzania. Tytuł raportu nad tabelą, scalone nagłówki, odstępy między blokami i wiersze z podsumowaniami pomagają w prezentacji, ale w Power Query mogą zostać potraktowane jak zwykłe rekordy. Docelowo każdy wiersz powinien opisywać jeden rekord, a każda kolumna — jeden atrybut. Od uporządkowania tego układu warto zacząć, zanim przejdziesz do przekształcania wartości. Na szkoleniach Cognity pokazujemy krok po kroku, jak przygotować strukturę tabeli do dalszej pracy w Power Query — poniżej przedstawiamy najważniejsze zasady tego procesu.

Nagłówki: najpierw znajdź właściwy wiersz

Jeśli po imporcie widzisz nazwy Column1, Column2 i Column3, sprawdź, gdzie znajdują się rzeczywiste nazwy pól. Gdy poprzedzają je tytuł raportu, data wygenerowania lub komentarz, najpierw usuń odpowiednią liczbę górnych wierszy. Dopiero później zastosuj polecenie Użyj pierwszego wiersza jako nagłówków. Odwrotna kolejność sprawi, że nazwami kolumn staną się elementy opisu raportu.

Nagłówki wielopoziomowe wymagają innego podejścia. Jeżeli pierwszy poziom wskazuje kategorię, a drugi miarę, trzeba utworzyć z nich jednoznaczne nazwy, na przykład Sprzedaż — ilość i Sprzedaż — wartość. Samo promowanie jednego wiersza nie zachowa całego znaczenia takiej struktury. Po operacji sprawdź również, czy nazwy są unikalne i czy pierwszy rekord nie został omyłkowo wykorzystany jako nagłówek.

Puste wiersze i podsumowania: rozdziel dwa rodzaje porządkowania

Puste wiersze często pełnią funkcję wizualnych separatorów. Możesz je usunąć poleceniem Usuń puste wiersze, ale pamiętaj, że dotyczy ono wierszy pustych w całości. Rekord z pustym polem w jednej kolumnie i wartościami w pozostałych nie jest pustym wierszem.

Osobnego filtrowania wymagają wiersze opisowe, powtórzone nagłówki oraz pozycje typu „Razem” lub „Suma”. Pozostawienie podsumowania obok rekordów szczegółowych może prowadzić do podwójnego zliczenia wyników. Usuwaj takie wiersze według rozpoznawalnej cechy, na przykład etykiety w kolumnie opisowej. Odrzucanie każdego wiersza bez identyfikatora jest zasadne tylko wtedy, gdy identyfikator rzeczywiście musi występować w każdym poprawnym rekordzie.

Zbędne kolumny: usuwać wskazane czy zachować wybrane?

Puste kolumny rozdzielające bloki, pomocnicze numeracje i pola służące wyłącznie do prezentacji utrudniają dalszą pracę. Power Query pozwala uporządkować je na dwa podstawowe sposoby:

• Usuń kolumny — gdy chcesz odrzucić kilka konkretnych pól, a pozostałe zachować.
• Wybierz kolumny — gdy znasz docelowy zakres tabeli i potrzebujesz tylko wskazanych pól.

Przed usunięciem kolumny sprawdź, czy nie będzie potrzebna do filtrowania, łączenia tabel lub identyfikacji rekordów. Pole nieprzydatne w końcowym raporcie może być niezbędne na wcześniejszym etapie przekształceń.

Przesunięcia danych: ustal, czy problem dotyczy całej tabeli

Jeśli wartości trafiają pod niewłaściwe nagłówki, porównaj kilka kolejnych wierszy z układem źródłowym. Inaczej naprawia się całą tabelę poprzedzoną pustą kolumną, a inaczej pojedyncze rekordy, w których pola zostały przesunięte. Zmiana nazwy kolumny nie naprawia błędnego przypisania wartości.

Przy regularnym przesunięciu można uporządkować układ wspólną operacją. Gdy problem dotyczy tylko części wierszy, najpierw trzeba je jednoznacznie rozpoznać i ustalić regułę korekty; bez niej bezpieczniej poprawić źródło. Nie przesuwaj całej kolumny, aby naprawić pojedynczy rekord — rozdzielisz wartości należące do pozostałych rekordów. Po zmianach sprawdź zgodność nagłówków z zawartością oraz liczbę wierszy, uwzględniając świadomie usunięte separatory i podsumowania.

Jakość danych: duplikaty, braki danych i niespójne wartości

Nie każdy problem w Power Query kończy się komunikatem o błędzie. Zapytanie może odświeżyć się poprawnie, a mimo to zwrócić zawyżoną sprzedaż, niepełną listę klientów lub kilka kategorii opisujących to samo zjawisko. Duplikaty, braki danych i niespójne wartości wymagają różnych działań: ustalenia unikalności rekordów, określenia zasad uzupełniania luk oraz ujednolicenia znaczenia wpisów.

Duplikaty: najpierw ustal, co oznacza unikalny rekord

Dwa wiersze z tym samym numerem zamówienia nie muszą być duplikatami — mogą przedstawiać różne pozycje jednego zakupu. Zanim użyjesz polecenia Usuń duplikaty, określ, co reprezentuje pojedynczy wiersz i które kolumny pozwalają go jednoznacznie rozpoznać. Dla pozycji zamówienia może to być połączenie numeru zamówienia i numeru pozycji, a nie sam identyfikator klienta.

Power Query sprawdza powtórzenia na podstawie zaznaczonych kolumn. Wybranie zbyt wąskiego zestawu może więc usunąć prawidłowe dane. Bezpiecznym krokiem diagnostycznym jest grupowanie według planowanego klucza i zliczenie wierszy w każdej grupie. Dzięki temu zobaczysz, gdzie występują powtórzenia, zanim zdecydujesz o ich usunięciu.

Jeżeli rekordy mają ten sam klucz, lecz różnią się pozostałymi wartościami, potrzebujesz reguły wyboru, na przykład zachowania wersji z najnowszą datą aktualizacji. Samo usunięcie duplikatów nie gwarantuje zachowania konkretnego wiersza; nie należy też zakładać, że wcześniejsze sortowanie wystarczy. W takim przypadku zastosuj grupowanie i jawne kryterium wyboru rekordu, uwzględniając również ewentualne remisy.

Braki danych: nie zastępuj każdej luki zerem

Wartość null oznacza brak wartości, a nie liczbę zero. Pusty tekst również nie jest tym samym co null. To rozróżnienie wpływa na wyniki: zastąpienie brakującej kwoty zerem może zaniżyć średnią i sugerować, że transakcja miała wartość zerową, choć w rzeczywistości kwoty nie podano.

Sposób postępowania powinien wynikać z roli kolumny:

• Brak kluczowego identyfikatora — wydziel rekordy do kontroli; ich automatyczne usunięcie może ukryć problem w źródle.
• Brak opcjonalnego opisu — pozostaw brak albo przypisz uzgodnioną etykietę, na przykład „Nie podano”, jeśli jest potrzebna w raporcie.
• Wartość podana tylko w pierwszym wierszu grupy — rozważ polecenie Wypełnij w dół, ale wyłącznie wtedy, gdy kolejne wiersze rzeczywiście dziedziczą tę informację. Operacja uzupełnia wartości null i bez odpowiedniego ograniczenia może przenieść dane między grupami.

Niespójne wartości: uporządkuj nazewnictwo według słownika

Wpisy „przelew”, „Przelew bankowy” i „PRZELEW” mogą oznaczać tę samą metodę płatności, ale w zestawieniu utworzyć odrębne kategorie. Przy kilku znanych wariantach wystarczy kontrolowana zamiana całych wartości. Jeśli wariantów jest więcej lub regularnie przybywają, lepiej przygotować tabelę mapowania z wartością źródłową i odpowiadającą jej nazwą standardową, a następnie scalić ją z danymi.

Nie łącz kategorii wyłącznie dlatego, że brzmią podobnie. Przykładowo „anulowane” i „zwrócone” mogą opisywać różne zdarzenia. Mapowanie powinno odzwierciedlać przyjęte definicje biznesowe, a wartości bez dopasowania warto kierować do osobnej kontroli zamiast automatycznie przypisywać je do kategorii „Inne”.

Skuteczność zmian sprawdzaj na liczbach: porównaj liczbę wierszy, unikalnych kluczy, braków i nierozpoznanych kategorii przed przekształceniami oraz po nich. Pomogą w tym narzędzia profilowania kolumn w zakładce Widok. Pamiętaj, że domyślnie profilowanie obejmuje pierwsze 1000 wierszy — do pełnej kontroli przełącz je na cały zestaw danych.

6. Zmiany w źródłach: rozjechane schematy plików, kolumny o zmiennych nazwach i kolejności

Zapytanie działało przez kilka miesięcy, a po dodaniu kolejnego pliku odświeżanie kończy się błędem „Nie znaleziono kolumny”? Przyczyną może być zmiana schematu źródła, czyli zestawu nazw i układu pól, których oczekują kolejne kroki. Power Query odtwarza zapisaną logikę przekształceń — nie rozpoznaje samodzielnie, że kolumna „Wartość sprzedaży” zastąpiła dotychczasową „Kwotę”.

Odporne zapytanie powinno tolerować zmiany techniczne, ale sygnalizować brak danych niezbędnych do analizy. Inaczej należy potraktować dodatkową kolumnę z komentarzem, a inaczej usunięcie identyfikatora transakcji. Próba ukrycia każdego błędu może sprawić, że raport odświeży się poprawnie, lecz pokaże niepełne wyniki.

Zmieniona nazwa kolumny a zmieniona kolejność

Zmiana nazwy najczęściej przerywa działanie kroku, który odwołuje się do starego nagłówka. Sprawdź kroki w panelu „Zastosowane kroki” i znajdź pierwszy, w którym pojawia się błąd. Jeśli źródło rzeczywiście zmieniło nazewnictwo, dostosuj odwołania albo dodaj wcześniej krok normalizujący nazwy. Przy kilku znanych wariantach eksportu warto sprowadzać je do jednego standardu, zanim rozpoczną się właściwe przekształcenia.

Sama zmiana kolejności kolumn zwykle nie stanowi problemu, jeśli operacje wskazują pola po nazwach. Staje się ryzykowna wtedy, gdy zapytanie wybiera „pierwszą” lub „trzecią” kolumnę, na przykład za pomocą indeksu listy nazw. Odwołania po nazwach są zazwyczaj bezpieczniejsze niż odwołania po pozycji. Jeżeli odbiorca raportu wymaga określonego układu, kolejność najlepiej ustalić na końcu.

Łączenie plików o różnych schematach

Przy imporcie z folderu sprawdź nie tylko zapytanie wynikowe, lecz także przekształcenia pliku przykładowego. Mechanizm łączenia stosuje przygotowaną funkcję do kolejnych plików. Jeżeli funkcja wymaga kolumny obecnej wyłącznie w części eksportów, błąd może wystąpić jeszcze przed ich połączeniem. Z kolei krok rozwijania z ustaloną listą kolumn nie uwzględni automatycznie wszystkich nowych pól.

Ujednolicenie nazw i zestawu kolumn warto więc wykonywać wewnątrz funkcji przetwarzającej pojedynczy plik. Zachowaj również nazwę pliku źródłowego, aby szybko ustalić, który eksport odbiega od standardu. Do folderu wejściowego powinny trafiać wyłącznie pliki objęte tym samym procesem — pliki tymczasowe i inne raporty należy odfiltrować przed łączeniem.

Brakujące i dodatkowe kolumny: ustal zasady obsługi

Podziel pola na wymagane i opcjonalne. Brak wymaganej kolumny powinien zatrzymać przetwarzanie z czytelnym komunikatem. Dla pól opcjonalnych można przyjąć wartość null. Przykładowo, po wcześniejszym sprawdzeniu obecności wymaganych pól „ID” i „Kwota”, poniższy krok zachowa docelowy zestaw kolumn i uzupełni brakujący „Komentarz”:

Table.SelectColumns(
    Źródło,
    {"ID", "Kwota", "Komentarz"},
    MissingField.UseNull
)

Ten krok odrzuci też dodatkowe kolumny. Jest odpowiedni, gdy raport ma stały zakres, ale nie wtedy, gdy powinien przejmować wszystkie nowe pola. MissingField.UseNull nie zastępuje kontroli schematu: bez wcześniejszej walidacji uzupełniłby również brakujące kolumny wymagane. Po zmianie zapytania przetestuj je na starszym pliku, nowym eksporcie oraz pliku bez pola obowiązkowego — dzięki temu sprawdzisz zarówno zgodność, jak i działanie zabezpieczeń.

Kodowanie i tekst: encoding, polskie znaki, znaki niedrukowalne i błędy importu

Nieczytelne polskie litery łatwo zauważyć. Trudniej wykryć niewidoczny znak, przez który dwie pozornie identyczne nazwy nie pasują do siebie podczas scalania zapytań. W Power Query warto rozdzielić te problemy: kodowanie decyduje o tym, jak odczytywane są znaki z pliku, a oczyszczanie tekstu usuwa niepożądane znaki z już odczytanych wartości. Te działania nie są zamienne — usunięcie spacji nie naprawi błędnie zinterpretowanego „ł”.

Nieprawidłowe polskie znaki — zacznij od ustawień importu

Jeżeli po wczytaniu pliku CSV lub TXT zamiast liter „ą”, „ę” czy „ś” pojawiają się przypadkowe ciągi znaków, sprawdź kodowanie w ustawieniach źródła. W oknie importu tekstu/CSV odpowiada za nie pole Pochodzenie pliku. UTF-8 jest powszechne we współczesnych eksportach, natomiast Windows-1250 można spotkać w starszych plikach przygotowanych w środowisku Windows. Samo rozszerzenie CSV nie wskazuje, którego kodowania użyto.

Wybierz kodowanie zgodne ze źródłem i zweryfikuj w podglądzie kilka wartości zawierających polskie litery. Nie naprawiaj takich błędów przez masową zamianę poszczególnych znaków — to usuwa objawy, ale nie przyczynę. Jeśli widzisz symbol „�”, ponowny odczyt oryginalnego pliku z właściwym kodowaniem może rozwiązać problem. Gdy jednak uszkodzony tekst został już zapisany w pliku źródłowym, sama zmiana ustawień importu nie odtworzy utraconych liter; potrzebny będzie poprawny eksport.

Niewidoczne znaki — przycinanie to nie pełne oczyszczanie

Tekst kopiowany ze stron internetowych, dokumentów lub systemów biznesowych może zawierać tabulatory, znaki końca wiersza, twarde spacje albo znaki o zerowej szerokości. Ich obecność bywa przyczyną niedopasowanych kluczy przy łączeniu danych, mimo że wartości wyglądają identycznie.

• Przycinanie tekstu usuwa białe znaki z początku i końca wartości. Nie usuwa odstępów wewnątrz tekstu.
• Oczyszczanie tekstu usuwa znaki sterujące, na przykład tabulatory i znaki nowego wiersza. Nie jest jednak uniwersalnym sposobem na wszystkie niewidoczne znaki Unicode.
• Celowana zamiana przydaje się po rozpoznaniu konkretnego znaku, np. twardej spacji wewnątrz nazwy. Można zastąpić ją zwykłą spacją, zachowując odstęp między wyrazami.

Przed oczyszczaniem sprawdź znaczenie znaków w danej kolumnie. Usunięcie końca wiersza z opisu może skleić dwa słowa, a usunięcie wszystkich spacji z identyfikatora — zmienić jego wartość. Transformacje stosuj więc do wybranych pól, nie automatycznie do całego zestawu danych.

Błędy odczytu CSV nie zawsze wynikają z kodowania

Jeżeli litery są poprawne, ale tekst zostaje rozdzielony w niewłaściwych miejscach, sprawdź separator oraz sposób obsługi cudzysłowów. Separator lub podział wiersza może być legalną częścią pola tekstowego, jeśli eksport prawidłowo ujmuje je w cudzysłowy. Niedomknięty cudzysłów w źródle może natomiast zaburzyć odczyt kolejnych rekordów.

Najpierw ustal, czy problem dotyczy odczytu znaków, interpretacji pliku czy zawartości tekstu. Dopiero potem dobierz naprawę i sprawdź ją na oryginalnym pliku — najlepiej na wartościach z polskimi literami, cudzysłowami oraz wielowierszowymi opisami.

Stabilność i wydajność: błędy po odświeżeniu, wolne zapytania oraz poziomy prywatności

Poprawny podgląd w edytorze Power Query nie gwarantuje, że odświeżenie zakończy się sukcesem. Podgląd może korzystać z ograniczonej liczby wierszy lub danych zapisanych w pamięci podręcznej, natomiast pełne odświeżenie wymaga ponownego dostępu do źródeł i przetworzenia danych potrzebnych do uzyskania wyniku. Dlatego problemy warto rozdzielić na trzy obszary: dostęp i warunki wykonania, wydajność przekształceń oraz zasady łączenia źródeł. Każdy wymaga innego sposobu diagnozy.

Błędy po odświeżeniu: sprawdź, gdzie wykonywane jest zapytanie

Jeśli zapytanie działało wcześniej, zacznij od szczegółów błędu. Sprawdź dostępność źródła, ważność poświadczeń oraz uprawnienia konta używanego przy odświeżaniu. Wygaśnięta sesja, niedostępny folder sieciowy czy przekroczony limit czasu mogą zatrzymać proces, mimo że same przekształcenia są poprawne.

Istotne jest również środowisko uruchomienia. Zapytanie działające w Power BI Desktop nie musi odświeżyć się w usłudze Power BI bez dodatkowej konfiguracji. W przypadku lokalnych źródeł potrzebna może być brama danych, która musi działać i mieć dostęp do właściwych zasobów. Ścieżka dostępna na komputerze autora raportu niekoniecznie będzie dostępna dla konta obsługującego bramę.

Najpierw ustal więc, czy problem występuje również przy odświeżeniu lokalnym, czy wyłącznie w harmonogramie. To pozwala zawęzić poszukiwania do zapytania albo konfiguracji środowiska, zamiast zmieniać działające kroki na ślepo.

Wolne zapytania: ogranicz pracę, zanim wykonasz kosztowne operacje

O czasie odświeżania decyduje nie tylko liczba wierszy, lecz także miejsce i kolejność wykonywania przekształceń. W źródłach, które to obsługują, Power Query może przekazać część operacji do systemu źródłowego. Mechanizm ten, nazywany query folding, pozwala na przykład odfiltrować rekordy w bazie, zamiast pobierać całą tabelę i dopiero później przetwarzać ją lokalnie.

W praktyce warto możliwie wcześnie ograniczać zakres danych do rzeczywiście potrzebnych, o ile nie zmienia to wyniku obliczeń. Sortowanie, grupowanie i scalanie dużych zbiorów lepiej wykonywać po takim ograniczeniu. Nie każdy konektor i nie każdy krok obsługuje jednak query folding; import pliku CSV nie daje takich samych możliwości jak zapytanie do bazy danych.

Unikaj optymalizacji opartych wyłącznie na przeczuciu. Porównuj czas pełnego odświeżenia przed zmianą i po niej, a tam, gdzie jest dostępna, korzystaj z diagnostyki zapytań. Buforowanie nie jest uniwersalnym przyspieszeniem: może zwiększyć zużycie pamięci i uniemożliwić przekazywanie kolejnych operacji do źródła. W Cognity łączymy teorię z praktyką — dlatego diagnozowanie i optymalizację zapytań Power Query rozwijamy także w formie ćwiczeń na szkoleniach.

Privacy Levels: ochrona danych, a nie ustawienie szybkości

Poziomy prywatności określają zasady izolowania danych podczas łączenia źródeł. Mają chronić przed niezamierzonym przekazaniem informacji z jednego źródła do drugiego, na przykład wykorzystaniem poufnych wartości w zapytaniu wysyłanym do zewnętrznej usługi. Nie zastępują uprawnień dostępu ani uwierzytelniania.

• Publiczny — dla danych dostępnych publicznie, których udostępnienie nie wymaga ochrony.
• Organizacyjny — dla danych przeznaczonych do udostępniania w zaufanym obszarze organizacji.
• Prywatny — dla źródeł wymagających najściślejszej izolacji od innych źródeł.

Jeśli pojawia się komunikat Formula.Firewall, sprawdź zarówno klasyfikację źródeł, jak i sposób, w jaki zapytanie odwołuje się do innych zapytań oraz pobiera dane. Nie każdy taki błąd wynika z niezgodnych poziomów prywatności. Nie wyłączaj też ich sprawdzania wyłącznie po to, by usunąć komunikat lub skrócić odświeżanie — taka zmiana może znieść ochronę przed ujawnieniem danych.

Power BI zaawansowany – optymalizacja raportów i poprawa ich wydajności 05 października 2026

Power BI zaawansowany – jak tworzyć profesjonalne modele danych 03 października 2026