Kwerendy w Access – jak filtrować, analizować i łączyć dane z różnych tabel?

Czym są kwerendy w Access i jak przygotować dane do pracy?

Kwerenda w Microsoft Access to zapisane zapytanie lub operacja wykonywana na danych. Pozwala uzyskać odpowiedź na konkretne pytanie, na przykład: które zamówienia czekają na realizację albo jaką wartość miała sprzedaż w danym miesiącu. Zamiast przeglądać wszystkie rekordy ręcznie, określasz, jakie informacje chcesz otrzymać i na jakich warunkach.

Tabela przechowuje dane, a kwerenda określa sposób ich odczytania lub przetworzenia. Zapisana kwerenda wybierająca przechowuje definicję zapytania, a nie osobną kopię wyników. Po ponownym uruchomieniu korzysta z aktualnych danych źródłowych. Może też dostarczać dane do formularza, raportu lub kolejnej kwerendy.

Do czego służą poszczególne rodzaje kwerend?

Najczęściej używa się kwerend wybierających, które wyświetlają potrzebne rekordy i pola. Kwerendy parametryczne pozwalają podać warunek przy uruchomieniu, na przykład wybrać okres analizy. Do zestawień zbiorczych służą kwerendy z podsumowaniami oraz kwerendy krzyżowe. Osobną grupę stanowią kwerendy modyfikujące: mogą zmieniać, dopisywać lub usuwać dane, dlatego wymagają większej ostrożności.

Zapytania można budować w graficznym widoku projektu albo zapisywać w języku SQL. Niezależnie od wybranego sposobu poprawność wyniku zależy przede wszystkim od struktury tabel i jakości zapisanych informacji.

Przygotuj tabele: jeden temat i jasno określony rekord

Zanim utworzysz pierwszą kwerendę, ustal, co oznacza pojedynczy rekord w każdej tabeli. W tabeli Klienci powinien opisywać jednego klienta, a w tabeli Zamówienia — jedno zamówienie. Dane kontaktowe klienta nie powinny być wielokrotnie przepisywane do kolejnych zamówień. Wystarczy przechowywać je w tabeli Klienci, a w zamówieniu zapisać identyfikator wskazujący właściwego klienta.

Każde pole powinno przechowywać jedną informację o określonym typie. Daty zapisuj jako daty, kwoty zwykle jako wartości typu Walutowy, a numery telefonu lub kody pocztowe jako tekst. Sam fakt, że wartość składa się z cyfr, nie oznacza, że należy traktować ją jak liczbę. Właściwe typy danych są niezbędne do poprawnego porównywania wartości i wykonywania obliczeń.

Klucze i relacje: jak powiązać informacje?

Klucz podstawowy jednoznacznie identyfikuje rekord. Musi być unikatowy i nie może pozostawać pusty. W Access często wykorzystuje się do tego pole typu Autonumerowanie. Nazwa klienta nie jest dobrym zamiennikiem identyfikatora: może się powtarzać lub zmienić.

Klucz obcy to pole wskazujące rekord w innej tabeli. Przykładowo pole IDKlienta w tabeli Zamówienia odwołuje się do klucza podstawowego tabeli Klienci. Tak powstaje relacja jeden-do-wielu: jeden klient może mieć wiele zamówień. Pola tworzące relację muszą mieć zgodne typy danych. Dla typowego klucza Autonumerowanie odpowiadającym kluczem obcym jest pole typu Liczba o rozmiarze Liczba całkowita długa.

Relacje definiuje się w oknie Relacje. Warto włączyć wymuszanie więzów integralności, jeśli struktura bazy na to pozwala. Dzięki temu Access nie dopuści na przykład do zapisania zamówienia z identyfikatorem klienta, który nie istnieje w tabeli Klienci.

Sprawdź dane przed utworzeniem kwerendy

Przed rozpoczęciem pracy usuń niezamierzone powtórzenia, sprawdź brakujące identyfikatory i ujednolić sposób zapisu kategorii oraz statusów. Ustal również, które pola są obowiązkowe, i zastosuj odpowiednie reguły poprawności. Pamiętaj, że pusta wartość nie oznacza tego samego co zero. Dobrze przygotowane źródło pozwala odróżnić błąd zapytania od problemu w samych danych — i znacznie ułatwia ocenę wiarygodności wyników.

Kwerendy SELECT w praktyce: filtrowanie, sortowanie, pola obliczeniowe i aliasy na danych firmowych

Kwerenda SELECT pozwala wybrać z bazy dokładnie te informacje, które są potrzebne do konkretnego zadania: listę nieopłaconych faktur, zamówienia z wybranego okresu czy produkty wymagające uzupełnienia zapasu. W Cognity często słyszymy pytania, jak praktycznie wykorzystać kwerendy SELECT w pracy z danymi firmowymi — odpowiadamy na nie także na blogu. Możesz ograniczyć zarówno liczbę wyświetlanych rekordów, jak i zakres widocznych pól, a następnie uporządkować wyniki i dodać własne obliczenia. Samo uruchomienie kwerendy SELECT nie zmienia danych źródłowych, choć niektóre wyniki można edytować w widoku arkusza danych — taka edycja może już zmienić zawartość tabel.

Wybór pól i filtrowanie rekordów

W Access najprościej zacząć od widoku projektu kwerendy: dodać źródło danych i przenieść potrzebne pola do siatki projektu. W zestawieniu należności mogą to być numer faktury, termin płatności, kwota oraz status zapłaty. Pominięcie zbędnych pól ułatwia czytanie wyników i ogranicza ilość informacji pobieranych przez kwerendę.

Warunki wyboru wpisujesz w wierszu Kryteria pod odpowiednimi polami. Przykładowo możesz wyświetlić wyłącznie faktury oznaczone jako nieopłacone, których termin płatności już minął. Pole wykorzystywane do filtrowania nie musi pojawiać się w wynikach — wystarczy wyłączyć dla niego opcję Pokaż.

W siatce projektu istotne jest położenie warunków:

• Kryteria w tym samym wierszu muszą być spełnione jednocześnie. Tak wybierzesz zamówienia, które mają określony status i przekraczają wskazaną kwotę.
• Kryteria w oddzielnych wierszach „lub” tworzą alternatywne zestawy warunków. Pozwalają uwzględnić rekordy spełniające jeden lub drugi zestaw.

Przy bardziej rozbudowanym filtrze sprawdź każdy wiersz osobno. Jeśli ograniczenie daty ma obowiązywać dla dwóch alternatywnych statusów, powinno znaleźć się w obu odpowiadających im wierszach. W przeciwnym razie część wyników może pochodzić spoza wybranego okresu.

Warunki dopasowuj do typu pola: liczby porównuj liczbowo, a daty jako daty. Jeżeli pole przechowuje również godzinę, zakres obejmujący cały miesiąc najbezpieczniej określić od jego początku włącznie do początku następnego miesiąca wyłącznie. Pamiętaj też, że brak wartości, czyli Null, nie oznacza zera ani pustego tekstu i wymaga osobnego warunku sprawdzającego.

Sortowanie wyników według priorytetu

W wierszu Sortuj ustawiasz porządek rosnący lub malejący. Dla zaległych faktur przydatne będzie sortowanie według terminu płatności od najstarszego, a dla zamówień — według wartości od najwyższej. Filtrowanie decyduje więc, które rekordy zobaczysz, natomiast sortowanie określa, w jakiej kolejności się pojawią.

Przy sortowaniu po kilku polach Access w widoku projektu nadaje pierwszeństwo polom od lewej do prawej. Możesz zatem uporządkować dokumenty najpierw według terminu płatności, a przy jednakowej dacie — według numeru. Dodatkowe, jednoznaczne kryterium porządku jest szczególnie użyteczne, gdy wiele rekordów ma tę samą wartość głównego pola sortowania.

Pola obliczeniowe i czytelne aliasy

Pole obliczeniowe wyznacza wartość na podstawie danych w rekordzie. W zestawieniu pozycji zamówień może to być wartość pozycji wynikająca z ilości i ceny jednostkowej, a w ewidencji faktur — kwota pozostała do zapłaty po odjęciu wpłat. Wynik takiego obliczenia nie jest automatycznie zapisywany w tabeli; kwerenda wylicza go podczas pobierania danych.

Przed dodaniem obliczenia ustal znaczenie jego składników: czy cena jest netto, czy brutto, jak zapisano rabat i co oznacza brak wartości. Null w jednym ze składników może spowodować, że wynik działania również będzie Null. Nie zastępuj go zerem bez sprawdzenia, czy odpowiada to zasadom przyjętym w danych firmowych.

Alias nadaje kolumnie wynikowej czytelną nazwę, na przykład „Pozostało do zapłaty”. Można go zastosować zarówno do pola obliczeniowego, jak i istniejącego pola źródłowego. Alias nie zmienia nazwy pola w tabeli, ale ułatwia interpretację zestawienia. Warto ustalić takie nazwy przed wykorzystaniem kwerendy w formularzach lub raportach, ponieważ późniejsza zmiana może wymagać poprawienia odwołań.

Kwerendy parametryczne w Access: formularze, kryteria i bezpieczne przekazywanie wartości

Kwerenda parametryczna pozwala wielokrotnie uruchamiać to samo zapytanie z innymi wartościami kryteriów — bez każdorazowej zmiany jego projektu. Możesz wskazać zakres dat sprzedaży, identyfikator klienta albo status zamówienia. Stała pozostaje logika zapytania, zmieniają się dane wejściowe. Parametry nie są przy tym osobnym sposobem łączenia czy analizowania danych: uzupełniają zapytanie o wartości dostarczane podczas jego wykonania.

Okno parametru czy formularz?

Najprostszy wariant to wpisanie w wierszu Kryteria, pod wybranym polem w widoku projektu, komunikatu w nawiasach kwadratowych, np. [Podaj identyfikator klienta:]. Przy uruchomieniu kwerendy Access wyświetli okno z prośbą o wartość. Takie rozwiązanie sprawdza się przy sporadycznym wyszukiwaniu, gdy użytkownik zna potrzebny identyfikator.

Do regularnej pracy wygodniejszy jest formularz. Pole kombi może wyświetlać nazwę klienta, a przekazywać jego identyfikator; kontrolki dat pomagają wskazać okres. W kryterium kwerendy można odwołać się bezpośrednio do kontrolki, np. [Forms]![frmFiltry]![txtDataOd]. To przykładowe nazwy obiektów — trzeba zastąpić je nazwami z własnej bazy.

Formularz musi być otwarty w chwili wykonywania kwerendy. Po zmianie kryteriów należy ponownie wykonać zapytanie lub odpytać źródło danych formularza wynikowego metodą Requery. Samo odświeżenie widoku nie zastępuje ponownego wykonania zapytania.

Deklarowanie typów parametrów

Typ parametru powinien odpowiadać typowi pola, z którym porównujesz wartość. Dla dat wybierz Data/Godzina, dla identyfikatora przechowywanego jako długa liczba całkowita — Liczba całkowita długa, a dla kodu tekstowego — Tekst. Kod zawierający zera na początku, np. 00125, nie powinien być traktowany jak liczba tylko dlatego, że składa się z cyfr.

Typy deklaruje się w oknie Parametry dostępnym podczas projektowania kwerendy albo w klauzuli PARAMETERS w widoku SQL. Nazwy muszą dokładnie odpowiadać parametrom użytym w kryteriach. W przypadku odwołania do formularza deklaracja powinna obejmować pełne odwołanie do kontrolki. Jawne określenie typów ogranicza błędną interpretację wartości; ma szczególne znaczenie przy datach oraz parametrach używanych w kwerendach krzyżowych.

Poniższy przykład zakłada tabelę Zamowienia z polem DataZamowienia oraz dwa parametry oznaczające daty podane bez godziny:

PARAMETERS [Data od:] DateTime, [Data do:] DateTime;
SELECT [IDZamowienia], [DataZamowienia]
FROM [Zamowienia]
WHERE [DataZamowienia] >= [Data od:]
  AND [DataZamowienia] < DateAdd("d", 1, [Data do:]);

Warunek końcowy uwzględnia również zamówienia z godziną zapisaną w ostatnim wskazanym dniu. Porównanie <= [Data do:] z datą oznaczającą północ pominęłoby późniejsze zdarzenia tego dnia. Formularz powinien dodatkowo sprawdzać, czy data początkowa nie jest późniejsza od końcowej.

Najczęstsze pułapki w kryteriach

• Nieoczekiwane okno „Wprowadź wartość parametru”. Nie zawsze oznacza celowo utworzony parametr. Access może tak reagować na literówkę w nazwie pola, nieprawidłowe odwołanie do kontrolki albo zamknięty formularz. Najpierw sprawdź nazwy i dostępność obiektów.
• Puste pole formularza. Kontrolka bez wartości często zwraca Null. Porównanie pola z takim parametrem nie oznacza „pokaż wszystko”. Ustal, czy brak wartości ma blokować uruchomienie, czy wyłączać dane kryterium. Nie utożsamiaj też Null z pustym tekstem "".
• Niedopasowany typ. Pole kombi pokazujące nazwę może zwracać liczbę z kolumny powiązanej. Parametr należy dopasować do wartości faktycznie przekazywanej, nie do tekstu widocznego na ekranie.
• Niewłaściwe symbole wieloznaczne. Przy wyszukiwaniu fragmentu tekstu operatorem LIKE znaczenie mają ustawienia bazy. W trybie ANSI-89 używa się m.in. *, a w ANSI-92 — %. Samo przekazanie tekstu jako parametru nie włącza wyszukiwania fragmentów.

Bezpieczne parametry zamiast sklejania SQL

Jeżeli kwerendę uruchamiasz z VBA, przekazuj wartości przez kolekcję Parameters obiektu DAO QueryDef, zamiast doklejać zawartość kontrolek do tekstu SQL. Oddzielenie wartości od składni zapytania zapobiega interpretowaniu wpisanego tekstu jako kodu SQL i eliminuje typowe problemy z apostrofami oraz formatowaniem dat.

Parametry nie zastępują jednak walidacji: nadal trzeba kontrolować wymagane pola, dopuszczalne zakresy i poprawność wyborów. Nie służą również do podstawiania nazw tabel, kolumn ani kierunku sortowania. Jeśli interfejs pozwala wybierać takie elementy, program powinien mapować wybór na zamkniętą listę dozwolonych wariantów, a nie przyjmować dowolny tekst użytkownika.

Agregacje i grupowanie w Access: SUM, COUNT, AVG i HAVING

Kwerenda agregująca zamienia wiele szczegółowych rekordów w podsumowanie: wartość sprzedaży dla klienta, liczbę pozycji zamówienia albo średnią kwotę pozycji sprzedaży. Grupowanie określa, dla jakiego zestawu rekordów Access wykona obliczenia. Bez grupowania otrzymasz podsumowanie całego analizowanego zbioru; po pogrupowaniu według identyfikatora klienta — osobny wynik dla każdego klienta.

SUM, COUNT i AVG — co właściwie obliczają?

Wybór funkcji zależy od pytania biznesowego, ale równie ważne jest ustalenie, co reprezentuje pojedynczy wiersz danych. Jeżeli jest to pozycja zamówienia, liczba wierszy nie będzie liczbą zamówień, a średnia wartość pozycji nie będzie średnią wartością koszyka.

Null nie jest zerem. Dla kwot 100, 200 i Null funkcja AVG zwróci 150, ponieważ uwzględni dwie wartości. Zastąpienie braku danych zerem zmieni wynik na 100. Taką decyzję należy oprzeć na znaczeniu danych, a nie na chęci uzyskania kompletnego zestawienia. Różnica między COUNT(*) a COUNT dla konkretnego pola pomaga wykryć brakujące wartości.

Jak przygotować podsumowanie sprzedaży?

Załóżmy, że tabela Sprzedaz zawiera jeden rekord na pozycję sprzedaży oraz pola IdKlienta, DataSprzedazy i WartoscNetto. Aby obliczyć sprzedaż według klientów, w widoku projektu kwerendy włącz przycisk Sumy (Σ). W wierszu sumowania pozostaw grupowanie dla identyfikatora klienta, a dla kwoty wybierz sumowanie.

Każde dodatkowe pole z ustawionym grupowaniem zwiększa szczegółowość zestawienia. Dodanie daty sprzedaży rozbije wynik klienta na poszczególne wartości daty. Jeśli pole przechowuje również godzinę, mogą powstać grupy dla różnych momentów tego samego dnia. Dlatego w zestawieniu pozostaw tylko te wymiary, które odpowiadają na zadane pytanie.

Poniższa kwerenda podsumowuje sprzedaż z 2025 roku i pokazuje wyłącznie klientów, których łączna wartość sprzedaży netto przekroczyła 10 000:

SELECT [IdKlienta],
       Sum([WartoscNetto]) AS [SprzedazNetto],
       Count(*) AS [LiczbaPozycji],
       Avg([WartoscNetto]) AS [SredniaWartoscPozycji]
FROM [Sprzedaz]
WHERE [DataSprzedazy] >= DateSerial(2025, 1, 1)
  AND [DataSprzedazy] < DateSerial(2026, 1, 1)
GROUP BY [IdKlienta]
HAVING Sum([WartoscNetto]) > 10000;

WHERE i HAVING — dwa różne etapy filtrowania

WHERE ogranicza rekordy przed obliczeniami, a HAVING filtruje gotowe grupy. W przykładzie WHERE wybiera sprzedaż z określonego roku. Dopiero potem Access sumuje kwoty dla klientów, a HAVING odrzuca grupy niespełniające progu sprzedaży. W Cognity omawiamy tę różnicę zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników.

To rozróżnienie ma bezpośredni wpływ na wynik. Warunek WHERE [WartoscNetto] > 10000 uwzględniłby tylko pojedyncze pozycje droższe niż 10 000, pomijając mniejsze zakupy. Nie odpowiadałby więc na pytanie o klientów, którzy przekroczyli ten próg łącznie. W widoku projektu pole służące wyłącznie do filtrowania rekordów przed agregacją ustaw w wierszu sumowania jako Gdzie, zamiast po nim grupować.

Kontrola duplikatów przez grupowanie

Grupowanie pomaga także znaleźć powtarzające się kombinacje wartości. Jeżeli numer pozycji powinien być unikatowy w obrębie zamówienia, sprawdź parę IdZamowienia i NrPozycji:

SELECT [IdZamowienia], [NrPozycji], Count(*) AS [LiczbaWystapien]
FROM [Sprzedaz]
GROUP BY [IdZamowienia], [NrPozycji]
HAVING Count(*) > 1;

Wynik wskazuje grupy wymagające weryfikacji, nie rekordy do automatycznego usunięcia. Duplikat należy rozpoznawać według reguły biznesowej — identyczna kwota i data mogą wystąpić w kilku prawidłowych transakcjach. Nie grupuj przy tym po unikatowym identyfikatorze rekordu, ponieważ każdy wiersz utworzy osobną grupę i powtórzenia pozostaną niewidoczne.

Przed wykorzystaniem podsumowania sprawdź jeszcze poziom szczegółowości kwot. Jeżeli całkowita wartość zamówienia jest powtórzona przy każdej jego pozycji, zwykłe SUM zawyży sprzedaż. Z kolei do policzenia zamówień na podstawie ich pozycji przygotuj najpierw zbiór unikatowych identyfikatorów zamówień, a dopiero potem zlicz jego rekordy.

Kwerendy krzyżowe (Crosstab): analiza sprzedaży w czasie i według kategorii, formatowanie wyników

Które kategorie produktów sprzedają się najlepiej w poszczególnych miesiącach? Zwykłe zestawienie z podsumowaniami może zawierać poprawne wyniki, ale utrudniać ich porównanie. Kwerenda krzyżowa w Access przedstawia dane w macierzy: wybrane wartości stają się nagłówkami wierszy, inne — nagłówkami kolumn, a na ich przecięciu pojawia się wynik obliczenia, na przykład suma sprzedaży.

W odróżnieniu od kwerendy SELECT pokazującej szczegółowe rekordy kwerenda krzyżowa służy przede wszystkim do porównań. Sprawdza się przy analizie sezonowości, sprzedaży według kategorii czy liczby zamówień w kolejnych okresach. Przypomina układem tabelę przestawną, ale jej strukturę określa definicja kwerendy, a nie przeciąganie pól w gotowym zestawieniu.

Jak zaplanować układ zestawienia sprzedaży?

Najpierw określ, co chcesz porównać. Dla analizy miesięcznej sprzedaży według kategorii potrzebne są trzy elementy:

• Nagłówki wierszy: kategorie produktów, dzięki którym każda kategoria otrzyma osobny wiersz.
• Nagłówki kolumn: miesiące lub inne okresy, które mają znaleźć się obok siebie.
• Wartość: kwota sprzedaży podsumowana dla danej kategorii i okresu.

Źródłem może być tabela albo zapisana kwerenda udostępniająca potrzebne pola. Jeżeli dane pochodzą z kilku tabel, wygodnie jest najpierw przygotować jedno źródło do analizy. Powinno zawierać datę sprzedaży, kategorię oraz wartość wyrażoną według jednej zasady, na przykład wyłącznie kwoty netto. Mieszanie kwot netto z brutto lub różnych walut daje zestawienie, które wygląda prawidłowo, ale nie pozwala na rzetelne porównania.

W Access możesz skorzystać z Kreatora kwerend krzyżowych, dostępnego na karcie tworzenia obiektów, albo ustawić typ kwerendy krzyżowej w widoku projektu. W siatce projektu przypisujesz polom role: nagłówek wiersza, nagłówek kolumny i wartość. Nagłówków wierszy może być kilka, natomiast pole nagłówków kolumn i pole wartości są pojedyncze. Jeśli chcesz pokazać jednocześnie kwotę sprzedaży i liczbę transakcji, najprościej przygotować osobne zestawienia.

Miesiące w kolumnach: zadbaj o rok i kolejność

Sam numer miesiąca nie rozróżnia lat. Jeśli źródło obejmuje kilka lat, umieszczenie miesięcy w kolumnach bez dodatkowego ograniczenia połączy na przykład wszystkie stycznie. Dla raportu rocznego ogranicz zakres dat do jednego roku. Przy analizie wieloletniej możesz dodać rok jako kolejny nagłówek wiersza albo zastosować oznaczenia okresów w formacie rrrr-mm.

Poniższy przykład zakłada źródło o nazwie Sprzedaz z polami Kategoria, DataSprzedazy i WartoscSprzedazy. Tworzy zestawienie za 2025 rok, z kategoriami w wierszach i numerami miesięcy w kolumnach:

TRANSFORM Sum([WartoscSprzedazy]) AS [SumaSprzedazy]
SELECT [Kategoria]
FROM [Sprzedaz]
WHERE [DataSprzedazy] >= DateSerial(2025, 1, 1)
  AND [DataSprzedazy] < DateSerial(2026, 1, 1)
GROUP BY [Kategoria]
PIVOT Month([DataSprzedazy])
IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12);

Lista IN ustala kolejność kolumn i zapewnia obecność wszystkich dwunastu miesięcy, również tych bez sprzedaży. W widoku projektu odpowiada jej właściwość Nagłówki kolumn. Stały zestaw kolumn jest szczególnie przydatny, gdy kwerenda zasila raport lub formularz: brak transakcji w jednym miesiącu nie zmienia wtedy struktury wyniku.

Formatowanie wartości i obsługa pustych komórek

Dla kwot ustaw format walutowy albo liczbowy z odpowiednią liczbą miejsc dziesiętnych we właściwościach pola lub kontrolki raportu. Zachowaj liczbowy typ wyniku — funkcja Format() zwraca tekst, więc nie warto używać jej do formatowania wartości przeznaczonych do dalszych obliczeń. Czytelne podpisy miesięcy możesz nadać w raporcie, pozostawiając w kwerendzie stabilne nazwy kolumn.

Pusta komórka zwykle oznacza brak danych dla danej kombinacji kategorii i okresu, a nie potwierdzoną sprzedaż równą zero. Jeśli zasady raportowania pozwalają utożsamić brak transakcji z zerem, możesz użyć funkcji Nz() z jawnie wskazaną wartością zastępczą 0, na przykład w wyrażeniu kontrolki raportu. Takiej zamiany nie należy jednak stosować do maskowania brakujących kwot w danych źródłowych.

Przed udostępnieniem zestawienia porównaj jego łączną wartość z podsumowaniem źródła dla tego samego zakresu dat. Pamiętaj też, że stałe nagłówki zapewniają obecność kolumn, ale nie dodają kategorii, których w wybranym okresie w ogóle nie ma w źródle.

Łączenia tabel w Access: INNER JOIN, LEFT JOIN i RIGHT JOIN

Gdy dane klienta znajdują się w jednej tabeli, a jego zamówienia w drugiej, kwerenda musi powiązać odpowiednie rekordy. Służy do tego JOIN, czyli złączenie tabel według wskazanego warunku. Najczęściej warunek porównuje klucz podstawowy z odpowiadającym mu kluczem obcym, np. pole KlientID w tabelach Klienci i Zamowienia. Wybór rodzaju złączenia decyduje natomiast o tym, czy wynik obejmie wyłącznie dopasowane rekordy, czy również te, które nie mają odpowiednika w drugiej tabeli.

INNER, LEFT i RIGHT JOIN — który typ wybrać?

W złączeniach zewnętrznych, czyli LEFT i RIGHT JOIN, brak dopasowania powoduje, że pola pobierane z brakującego rekordu mają wartość Null. Nie oznacza ona zera ani pustego tekstu. RIGHT JOIN działa analogicznie do LEFT JOIN po zamianie kolejności tabel — wybór między nimi często wynika z czytelności zapisu.

W widoku projektu kwerendy Access kliknij dwukrotnie linię łączącą tabele, aby otworzyć Właściwości sprzężenia. Możesz tam wybrać wyłącznie dopasowane rekordy albo wszystkie rekordy z jednej tabeli i dopasowania z drugiej. Czytaj opis opcji z nazwami tabel: samo położenie ich okien w projektancie nie jest wystarczającą wskazówką.

Relacja jeden-do-wielu: dlaczego klient pojawia się kilka razy?

W relacji jeden-do-wielu jeden klient może mieć wiele zamówień. Po połączeniu tabel klient z trzema zamówieniami pojawi się więc w trzech wierszach. To prawidłowy wynik, a nie automatycznie błąd lub duplikat: każdy wiersz opisuje inne zamówienie wraz z danymi klienta.

Przed dodaniem kolejnej tabeli ustal, co ma reprezentować pojedynczy wiersz wyniku: klienta, zamówienie czy pozycję zamówienia. Dołączenie tabeli PozycjeZamowien może zmienić szczegółowość wyniku z jednego wiersza na zamówienie na jeden wiersz na jego pozycję. Wtedy wartość całego zamówienia będzie powtarzana przy każdej pozycji. Jej późniejsze sumowanie zawyży wynik.

Relacja wiele-do-wielu: łączenie przez tabelę pośrednią

Jedno zamówienie może obejmować wiele produktów, a ten sam produkt może występować w wielu zamówieniach. Takie powiązanie odwzorowuje tabela pośrednia, np. PozycjeZamowien, zawierająca pola ZamowienieID i ProduktID, a także informacje dotyczące pozycji, takie jak ilość i cena sprzedaży.

W kwerendzie łączysz zatem Zamowienia z PozycjeZamowien, a następnie PozycjeZamowien z Produkty. Nie łącz bezpośrednio identyfikatora zamówienia z identyfikatorem produktu: podobna nazwa lub ten sam typ pola nie oznaczają wspólnego znaczenia danych.

Jak wykrywać brakujące dopasowania i błędne wyniki?

LEFT JOIN przydaje się do wyszukiwania rekordów bez powiązań. Poniższa kwerenda zwraca klientów, którzy nie mają żadnego zamówienia:

SELECT K.KlientID, K.Nazwa
FROM Klienci AS K
LEFT JOIN Zamowienia AS Z
    ON K.KlientID = Z.KlientID
WHERE Z.ZamowienieID IS NULL;

Warunek sprawdza klucz podstawowy zamówienia, który w istniejącym rekordzie nie może być pusty. Dzięki temu wykrywa brak dopasowania, a nie przypadkowo niewypełnione pole opisowe.

Jeżeli wynik kwerendy jest nieoczekiwany, sprawdź przede wszystkim:

• Warunek łączenia. Łączenie po nazwie zamiast po identyfikatorze może tworzyć przypadkowe dopasowania. Tabele bez warunku łączenia mogą natomiast dać iloczyn kartezjański — każdą kombinację ich rekordów.
• Liczbę dopasowań. Dołączaj tabele pojedynczo i kontroluj liczbę wierszy oraz identyfikatory. Pozwoli to ustalić, które złączenie zwielokrotnia wynik i czy jest to zgodne z oczekiwaną szczegółowością.
• Kryteria po stronie opcjonalnej. Po LEFT JOIN warunek w WHERE, np. wymagający konkretnego statusu zamówienia, odrzuci wiersze bez zamówień. Jeśli chcesz zachować wszystkich klientów, możesz najpierw odfiltrować zamówienia w osobnej kwerendzie, a następnie dołączyć jej wynik.
• Zgodność pól. Porównywane pola muszą mieć zgodne typy danych. Typowemu kluczowi Autonumerowanie odpowiada klucz obcy typu Liczba z rozmiarem Długa liczba całkowita.

Nie maskuj nieprawidłowego złączenia przez automatyczne usuwanie powtórzeń. Najpierw ustal, dlaczego rekord ma wiele dopasowań — inaczej pozornie poprawna lista może nadal prowadzić do błędnej analizy.

Kwerendy modyfikujące w Access: UPDATE, APPEND i DELETE — bezpieczna zmiana danych

Kwerendy modyfikujące nie służą do wyświetlania wyników, lecz do wprowadzania zmian w tabelach. Pozwalają jednocześnie poprawić tysiące rekordów, dołączyć dane z importu lub usunąć niepotrzebne wpisy. Ta wygoda wymaga ostrożności: zmian wykonanych przez taką kwerendę nie można cofnąć zwykłym poleceniem Cofnij. Przed jej uruchomieniem trzeba sprawdzić zakres operacji i przygotować sposób odzyskania danych.

Aktualizowanie, dołączanie i usuwanie — co wybrać?

Rodzaj kwerendy należy dopasować do tego, czy zmieniasz istniejące rekordy, dodajesz nowe, czy usuwasz całe wpisy:

• UPDATE — kwerenda aktualizująca: zmienia wartości wskazanych pól w istniejących rekordach. Przydaje się np. do aktualizacji cen wybranej grupy produktów lub zmiany statusu zamówień spełniających określone warunki.
• APPEND — kwerenda dołączająca: dodaje nowe rekordy do istniejącej tabeli. W języku SQL odpowiada jej instrukcja INSERT INTO. Typowe zastosowanie to przeniesienie zweryfikowanych danych z tabeli importowej do tabeli docelowej. Nie aktualizuje rekordów, które już się w niej znajdują.
• DELETE — kwerenda usuwająca: usuwa całe rekordy spełniające kryteria. Jeśli chcesz jedynie wyczyścić zawartość pojedynczego pola, użyj aktualizacji, o ile reguły tego pola dopuszczają pustą wartość.

Brak kryteriów w kwerendzie aktualizującej lub usuwającej może objąć zmianą wszystkie rekordy tabeli. Sam komunikat z liczbą przetwarzanych wpisów nie wystarcza do oceny, czy operacja jest poprawna.

Walidacja przed uruchomieniem kwerendy

Najpierw sprawdź rekordy wskazywane przez warunki operacji — najlepiej za pomocą osobnej kwerendy wybierającej z tymi samymi kryteriami. Porównaj ich liczbę z oczekiwaniami i przejrzyj przykładowe wpisy. Przy aktualizacji skontroluj zarówno dotychczasowe wartości, jak i planowany wynik obliczeń. Test na kopii bazy pozwoli dodatkowo wykryć skutki, których sam podgląd nie pokaże.

Przy dołączaniu danych sprawdź zgodność typów i rozmiarów pól, obecność wartości wymaganych oraz unikalność kluczy. Identyfikatory odwołujące się do innych tabel muszą wskazywać istniejące rekordy, jeśli obowiązuje integralność referencyjna. Dane z plików zewnętrznych warto najpierw umieszczać w tabeli roboczej: łatwiej wtedy wykryć braki i błędy przed przeniesieniem ich do właściwej bazy.

Przed usuwaniem sprawdź ustawienia relacji. Kaskadowe usuwanie rekordów pokrewnych może rozszerzyć skutki operacji na powiązane tabele. Bez tej opcji integralność referencyjna może zablokować usunięcie rekordu, do którego odwołują się inne wpisy. Nie należy wyłączać zabezpieczeń tylko po to, aby ominąć taki komunikat.

Transakcje: wszystkie zmiany albo żadna

Jeżeli proces wymaga kilku powiązanych operacji, powinny one stanowić jedną całość. Przykładem jest dołączenie zatwierdzonych danych do tabeli docelowej i późniejsze usunięcie ich z tabeli roboczej. Błąd drugiego kroku nie powinien pozostawić procesu w niejednoznacznym stanie.

W Access taki przebieg można kontrolować programowo, np. za pomocą transakcji DAO w VBA: rozpocząć transakcję, wykonać operacje, a następnie zatwierdzić całość albo wycofać ją po błędzie. Wymaga to prawidłowej obsługi błędów. Samo zapisanie kilku kwerend i uruchomienie ich kolejno nie zapewnia wspólnej transakcji. Przy tabelach połączonych z zewnętrznym źródłem trzeba również sprawdzić obsługę transakcji przez używany mechanizm dostępu.

Kopia bezpieczeństwa i kontrola efektów

Przed masową zmianą wykonaj kopię bazy zawierającej dane. W bazie podzielonej najważniejszy jest plik z tabelami, a nie wyłącznie plik z formularzami i kwerendami. Kopiowanie plikowej bazy zaplanuj po zakończeniu pracy użytkowników i zamknięciu połączeń. Jeśli dane znajdują się na serwerze, zastosuj właściwą dla niego procedurę tworzenia kopii.

Po wykonaniu operacji porównaj liczbę zmienionych rekordów z planem i sprawdź wartości istotne dla procesu, np. ceny, statusy lub liczbę dołączonych wpisów. Transakcja chroni przed niepełnym wykonaniem operacji, ale nie przed zatwierdzeniem błędnych kryteriów. Dlatego walidacja, transakcje i kopia bezpieczeństwa uzupełniają się — żaden z tych elementów nie zastępuje pozostałych.

Optymalizacja i diagnostyka: jak przyspieszyć kwerendy w Access

Wolna kwerenda nie zawsze oznacza zbyt dużą bazę. Przyczyną może być brak indeksu, przetwarzanie niepotrzebnych rekordów, kosztowne wyrażenie albo odczyt danych przez sieć. Zanim zmienisz konstrukcję zapytania, ustal, na którym etapie pojawia się opóźnienie. Inaczej optymalizuje się wyszukiwanie pojedynczego zamówienia, a inaczej zestawienie obejmujące kilka lat sprzedaży.

Indeksy — szybsze wyszukiwanie kosztem zapisu

Indeks pomaga silnikowi bazy odnaleźć rekordy bez przeglądania całej tabeli. Najczęściej warto indeksować pola używane w kryteriach wyszukiwania, połączeniach tabel i sortowaniu. Access automatycznie tworzy unikatowy indeks dla klucza podstawowego, natomiast indeksy na pozostałych istotnych polach trzeba sprawdzić w projekcie tabeli. Dotyczy to zwłaszcza kluczy obcych, takich jak identyfikator klienta w tabeli zamówień.

Najwięcej korzyści przynosi zwykle indeks na polu pozwalającym wybrać niewielką część danych. Indeksowanie pola o zaledwie kilku powtarzających się wartościach może dać mniejszy efekt. Jeśli często wyszukujesz dane według kilku pól jednocześnie, rozważ indeks wielopolowy. Kolejność jego pól ma znaczenie: indeks zaczynający się od identyfikatora klienta, a następnie daty zamówienia nie jest równoważny indeksowi z odwrotną kolejnością.

Nie indeksuj wszystkich kolumn na zapas. Każdy dodatkowy indeks zajmuje miejsce i wymaga aktualizacji przy dopisywaniu, usuwaniu oraz zmianie danych. Celem jest przyspieszenie rzeczywiście używanych kwerend, a nie maksymalna liczba indeksów.

Mniej pól i rekordów do przetworzenia

Zwracaj tylko kolumny potrzebne w danym formularzu, raporcie lub eksporcie. Pobieranie wszystkich pól, zwłaszcza długich tekstów i załączników, zwiększa ilość odczytywanych danych. Równie ważne jest ograniczenie zakresu rekordów: jeśli raport dotyczy jednego miesiąca, nie powinien niepotrzebnie przetwarzać całej historii sprzedaży.

Kryteria zapisuj tak, aby silnik mógł wykorzystać indeks. Przy wyszukiwaniu według dat zwykle lepiej porównywać pole z granicami okresu niż obliczać rok lub miesiąc osobno dla każdego rekordu. Funkcje i konwersje zastosowane bezpośrednio do przeszukiwanego pola mogą utrudniać użycie indeksu. Podobny problem dotyczy wyszukiwania fragmentu tekstu z symbolem wieloznacznym na początku wzorca.

Usuń także zbędne sortowania i eliminowanie duplikatów, jeżeli wynik ich nie wymaga. Samo zapisanie części operacji w pomocniczej kwerendzie nie gwarantuje przyspieszenia — o sposobie wykonania całości nadal decyduje optymalizator.

Plan wykonania i pomiar czasu

Plan wykonania pokazuje, jak silnik zamierza odczytywać i łączyć dane oraz czy korzysta z indeksów. Access nie udostępnia standardowego graficznego podglądu planu porównywalnego z narzędziami serwerowych baz danych. Zaawansowana diagnostyka może korzystać z mechanizmu ShowPlan dla Jet/ACE, ale sposób jego uruchomienia zależy od wersji silnika i konfiguracji środowiska; zwykle wymaga zmian w rejestrze Windows. To narzędzie diagnostyczne, nie ustawienie przyspieszające kwerendy.

W codziennej pracy zacznij od prostszego testu: uruchom kwerendę bez formularza lub raportu, a następnie porównaj jej warianty po usunięciu wybranych obliczeń, sortowania czy dodatkowego źródła danych. Zmieniaj jeden element naraz i sprawdzaj również poprawność wyniku. Porównuj czas pobrania całego zestawu, nie tylko pojawienia się pierwszych wierszy. Powtórz pomiar, ponieważ buforowanie danych może przyspieszać kolejne uruchomienia.

W Cognity łączymy teorię z praktyką — dlatego zagadnienia optymalizacji kwerend rozwijamy także w formie ćwiczeń na szkoleniach.

Typowe źródła opóźnień poza indeksami

• Nieprawidłowe połączenia tabel: niezamierzone zwielokrotnienie rekordów zwiększa koszt dalszego przetwarzania.
• Kosztowne obliczenia: wielokrotne wywołania funkcji VBA lub funkcji domenowych, takich jak DLookup, mogą wykonywać dodatkową pracę dla każdego wiersza.
• Tabele połączone: opóźnienia sieciowe i przetwarzanie danych lokalnie zamiast na serwerze mogą dominować nad czasem samego wyszukiwania.
• Rozrost pliku: po licznych zmianach danych warto rozważyć operację „Kompaktuj i napraw bazę danych”, po wykonaniu kopii bezpieczeństwa i zapewnieniu wyłącznego dostępu do pliku.

Jeśli źródłem jest baza serwerowa, sprawdź, czy filtrowanie i obliczenia można wykonać po jej stronie, na przykład za pomocą kwerendy przekazującej. W przypadku plikowej bazy Access oceń także jakość połączenia sieciowego oraz organizację pracy wielostanowiskowej. Nawet dobrze zaprojektowane indeksy nie usuną opóźnień wynikających z wolnego dostępu do pliku.

Jak zabezpieczyć bazę danych Access i zarządzać dostępem użytkowników? 19 listopada 2026

Data Governance w Power BI i Microsoft Fabric – jak zarządzać dostępem, jakością i bezpieczeństwem danych? 17 listopada 2026