Access kwerendy SQL — filtrowanie i analiza danych 2026

Kwerendy Access: SQL, filtrowanie i analiza danych w małej firmie

\n

Kwerendy w Microsoft Access są miejscem, w którym zwykła baza danych zaczyna realnie pracować dla firmy. To one odpowiadają na pytania typu: którzy klienci kupili najwięcej w tym kwartale, jakie faktury są przeterminowane, ile zamówień obsłużył dany handlowiec, które produkty trzeba domówić i jak przygotować zestawienie do Excela bez ręcznego kopiowania rekordów. W tym poradniku przejdziesz przez najważniejsze typy kwerend Access: wybierające, parametryczne, krzyżowe, aktualizujące, dołączające, usuwające i tworzące tabelę. Zobaczysz, jak działa widok projektu i widok SQL, jak łączyć tabele przez INNER JOIN, LEFT JOIN i RIGHT JOIN, jak pisać warunki WHERE, sortować ORDER BY, grupować GROUP BY oraz filtrować grupy przez HAVING. Omówimy też funkcje DSum, DCount i DLookup, podzapytania, eksport wyników do Excela oraz praktyczny model pracy z bazą danych dla małej firmy.

\n\n

Dlaczego kwerendy są sercem bazy Access

\n

Access bywa traktowany jak prostszy arkusz kalkulacyjny, ale to zbyt wąskie spojrzenie. Arkusz dobrze sprawdza się przy obliczeniach i jednorazowej analizie, natomiast Access przechowuje dane w tabelach relacyjnych, pilnuje typów pól, relacji i spójności rekordów. Kwerenda jest warstwą pośrednią między surowymi tabelami a raportem, formularzem, eksportem lub decyzją biznesową. Nie musisz każdorazowo przeglądać całej tabeli klientów, zamówień i płatności. Wystarczy zapisać kwerendę, która pobiera tylko potrzebne pola i rekordy.

\n

Microsoft w dokumentacji Access opisuje tworzenie zapytań jako sposób skupienia się na wybranych danych, na przykład przez kreator prostych zapytań albo widok projektu. Warto znać tę oficjalną ścieżkę, bo ułatwia start osobom, które nie piszą SQL codziennie: tworzenie zapytania, formularza lub raportu w programie Access. W praktyce najlepsze rezultaty daje połączenie dwóch trybów: widoku projektu do szybkiego budowania układu oraz widoku SQL do precyzyjnej kontroli warunków, aliasów i złączeń.

\n

Dla małej firmy kwerendy są szczególnie ważne, ponieważ pozwalają zastąpić wiele ręcznych czynności powtarzalnym procesem. Jeżeli prowadzisz bazę klientów, tabelę zamówień, tabelę produktów i tabelę płatności, możesz jednym kliknięciem przygotować listę zaległych należności, zestawienie sprzedaży według miesięcy albo listę klientów bez zamówienia w ostatnich 90 dniach. To nie wymaga systemu ERP. Wymaga sensownej struktury tabel, poprawnie zapisanych relacji i kwerend, które odpowiadają na konkretne pytania.

\n

Jeżeli dopiero kompletujesz środowisko Office do pracy z Accessem, zwróć uwagę, że Access jest składnikiem wyższych edycji pakietu Office dla Windows. W kontekście pracy biurowej i baz danych warto sprawdzić Microsoft Office 2024 Professional Plus, ponieważ taka edycja jest naturalnym wyborem dla użytkowników potrzebujących Accessa, Excela, Worda, Outlooka i PowerPointa w jednym zestawie. Przy mniej zaawansowanych stanowiskach wystarczający może być pakiet bez Accessa, ale dla osoby budującej i utrzymującej lokalną bazę firmową Access jest kluczowy.

\n\n

Przykładowy model danych dla małej firmy

\n

W dalszych przykładach przyjmiemy prosty model bazy: tabela Klienci, tabela Zamowienia, tabela PozycjeZamowien, tabela Produkty i tabela Platnosci. Tabela Klienci ma pole IDKlienta, nazwę, NIP, miasto i region. Tabela Zamowienia ma pole IDZamowienia, IDKlienta, datę zamówienia, status i identyfikator opiekuna. Tabela PozycjeZamowien przechowuje produkty, ilości i ceny, a tabela Platnosci przechowuje termin płatności, kwotę i datę zapłaty.

\n

Taki układ pozwala uniknąć dublowania danych. Nazwa klienta występuje w tabeli klientów, a nie w każdym zamówieniu. Produkt jest opisany w tabeli produktów, a pozycja zamówienia odwołuje się do niego identyfikatorem. Dzięki temu zmiana nazwy produktu lub adresu klienta nie wymaga poprawiania setek rekordów. Kwerendy łączą te tabele wtedy, gdy potrzebujesz czytelnego wyniku dla człowieka.

\n\n

Widok projektu i widok SQL: kiedy używać którego

\n

Access daje dwa podstawowe sposoby pracy z kwerendami. Widok projektu jest graficzny: wybierasz tabele, przeciągasz pola na siatkę, ustawiasz kryteria i sortowanie. Widok SQL pokazuje rzeczywiste polecenie SQL, które Access wykona. Osoba początkująca zwykle startuje od widoku projektu, ale z czasem warto nauczyć się czytać SQL, ponieważ pozwala szybciej diagnozować błędy, kopiować schematy kwerend i pisać warunki, które w siatce projektu stają się mało czytelne.

\n

Przełączanie między widokami jest normalną częścią pracy. Możesz rozpocząć od widoku projektu, dodać tabele i pola, a potem przejść do widoku SQL, żeby dopisać aliasy, funkcję agregującą albo bardziej złożony warunek. Po zapisaniu kwerendy Access zachowa ją jako obiekt w okienku nawigacji. Możesz użyć jej jako źródła danych dla formularza, raportu, kolejnej kwerendy albo eksportu do Excela.

\n

Ważne jest, aby od początku nazywać kwerendy według funkcji, a nie według kolejności tworzenia. Nazwy typu Kwerenda1, Kwerenda2 i TestFinalNowa szybko prowadzą do chaosu. Lepsze nazwy to qSprzedazMiesieczna, qKlienciBezZamowien90Dni, qPlatnosciPrzeterminowane albo qEksportZamowienDoExcela. Prefiks q nie jest obowiązkowy, ale pomaga odróżnić kwerendy od tabel i formularzy.

\n\n

Kwerendy wybierające SELECT: podstawowy sposób analizy danych

\n

Kwerenda wybierająca, czyli SELECT, nie zmienia danych. Pobiera rekordy i kolumny z jednej lub wielu tabel, stosuje warunki, sortowanie, obliczenia albo agregacje, a następnie pokazuje wynik w arkuszu danych. To najbezpieczniejszy i najczęściej używany typ kwerendy. Jeżeli uczysz się Access SQL, zacznij właśnie od SELECT, bo ta składnia pojawia się także jako etap testowania kwerend aktualizujących, usuwających i dołączających.

\n

Najprostsza kwerenda wybierająca wygląda tak:

\n

SELECT IDKlienta, NazwaFirmy, Miasto\nFROM Klienci;

\n

Ta kwerenda pobiera trzy pola z tabeli Klienci. Jeżeli chcesz zmienić nagłówek kolumny w wyniku, możesz użyć aliasu:

\n

SELECT NazwaFirmy AS Klient, Miasto AS Lokalizacja\nFROM Klienci;

\n

Alias nie zmienia nazwy pola w tabeli. Zmienia tylko nazwę kolumny w wyniku kwerendy. To przydatne, gdy wynik trafia do raportu, formularza albo Excela i ma być zrozumiały dla osoby, która nie zna struktury bazy.

\n\n

WHERE: filtrowanie rekordów

\n

Klauzula WHERE ogranicza rekordy przed wyświetleniem wyniku. W praktyce to najważniejszy element kwerendy operacyjnej. Microsoft opisuje filtrowanie danych w kwerendzie jako sposób pobierania wybranych wierszy i kolumn z tabel; szczegóły znajdziesz w dokumentacji: filtrowanie danych w kwerendzie.

\n

Przykład: lista klientów z Warszawy:

\n

SELECT IDKlienta, NazwaFirmy, Miasto\nFROM Klienci\nWHERE Miasto = 'Warszawa';

\n

Dla dat Access często używa znaków # wokół literału daty:

\n

SELECT IDZamowienia, IDKlienta, DataZamowienia, Status\nFROM Zamowienia\nWHERE DataZamowienia >= #2026-01-01#;

\n

Przy polskich ustawieniach regionalnych w widoku projektu możesz wpisywać daty lokalnie, ale w widoku SQL najbezpieczniej stosować jednoznaczny format roku, miesiąca i dnia. Jeżeli filtrujesz po przedziale dat, unikaj warunku tylko na miesiąc zapisany tekstowo. Lepszy jest zakres:

\n

SELECT IDZamowienia, DataZamowienia, Status\nFROM Zamowienia\nWHERE DataZamowienia >= #2026-04-01#\n  AND DataZamowienia < #2026-05-01#;

\n

Taki zapis działa dobrze także wtedy, gdy pole daty zawiera godzinę. Warunek < #2026-05-01# obejmuje cały kwiecień, a nie tylko rekordy do północy ostatniego dnia.

\n\n

ORDER BY: sortowanie wyników

\n

ORDER BY ustala kolejność rekordów w wyniku. Bez ORDER BY baza nie gwarantuje kolejności, nawet jeśli dane wydają się pojawiać według identyfikatora. Dla listy przeterminowanych płatności typowe sortowanie wygląda tak:

\n

SELECT IDPlatnosci, IDKlienta, TerminPlatnosci, Kwota\nFROM Platnosci\nWHERE DataZaplaty IS NULL\nORDER BY TerminPlatnosci ASC, Kwota DESC;

\n

Najpierw zobaczysz najstarsze terminy płatności, a przy tym samym terminie największe kwoty. To ma sens biznesowy: zaczynasz od najbardziej pilnych spraw. Sortowanie można ustawiać w widoku projektu w wierszu Sortuj, ale w widoku SQL łatwiej zauważyć, czy kolejność pól jest zgodna z priorytetem.

\n\n

LIKE, IN, BETWEEN i IS NULL

\n

W codziennej pracy przydają się operatory filtrujące. LIKE wyszukuje wzorzec tekstowy, IN sprawdza przynależność do listy wartości, BETWEEN filtruje zakres, a IS NULL znajduje puste wartości. Przykłady:

\n

SELECT NazwaFirmy, NIP\nFROM Klienci\nWHERE NazwaFirmy LIKE 'Auto*';

\n

SELECT IDZamowienia, Status\nFROM Zamowienia\nWHERE Status IN ('Nowe', 'W realizacji', 'Wstrzymane');

\n

SELECT IDPlatnosci, TerminPlatnosci, Kwota\nFROM Platnosci\nWHERE TerminPlatnosci BETWEEN #2026-04-01# AND #2026-04-30#;

\n

SELECT IDPlatnosci, Kwota\nFROM Platnosci\nWHERE DataZaplaty IS NULL;

\n

W Access symbol wieloznaczny w wielu typowych kwerendach to gwiazdka, czyli *. Jeżeli baza pracuje z ustawieniami zgodnymi z ANSI-92, możesz spotkać procent %. Warto sprawdzić ustawienia bazy, gdy filtr LIKE nie zwraca oczekiwanych wyników.

\n\n

JOIN: łączenie tabel INNER, LEFT i RIGHT

\n

Siła Accessa wynika z relacyjnego modelu danych. Zamiast trzymać wszystkie informacje w jednej szerokiej tabeli, rozdzielasz je na logiczne tabele i łączysz przez klucze. JOIN pozwala pobrać dane z kilku tabel w jednym wyniku. Typowe połączenie zamówień z klientami wygląda tak:

\n

SELECT Zamowienia.IDZamowienia,\n       Zamowienia.DataZamowienia,\n       Klienci.NazwaFirmy,\n       Klienci.Miasto\nFROM Klienci INNER JOIN Zamowienia\nON Klienci.IDKlienta = Zamowienia.IDKlienta;

\n

INNER JOIN zwróci tylko te rekordy, które mają dopasowanie po obu stronach. Jeżeli klient nie ma zamówień, nie pojawi się w wyniku. To jest właściwe, gdy analizujesz faktyczne zamówienia. Nie jest właściwe, gdy szukasz klientów bez aktywności.

\n\n

LEFT JOIN: znajdowanie braków i luk

\n

LEFT JOIN zwraca wszystkie rekordy z lewej tabeli oraz dopasowane rekordy z prawej. Jeżeli dopasowania nie ma, pola z prawej tabeli mają wartość Null. To świetny sposób na wykrywanie brakujących danych. Przykład: klienci bez żadnego zamówienia:

\n

SELECT Klienci.IDKlienta, Klienci.NazwaFirmy\nFROM Klienci LEFT JOIN Zamowienia\nON Klienci.IDKlienta = Zamowienia.IDKlienta\nWHERE Zamowienia.IDZamowienia IS NULL;

\n

Dla małej firmy taka kwerenda bywa bardziej wartościowa niż ranking sprzedaży. Pokazuje kontakty, które trafiły do bazy, ale nigdy nie przeszły w sprzedaż. Możesz przekazać tę listę handlowcowi, przygotować kampanię przypominającą albo sprawdzić, czy import klientów nie zawiera nieaktywnych duplikatów.

\n\n\n\n\n\n\n\n\n\n\n

Typ złączenia	Co zwraca	Typowe pytanie biznesowe	Przykład zastosowania
INNER JOIN	Tylko rekordy z dopasowaniem w obu tabelach	Jakie zamówienia mają przypisanego klienta?	Raport sprzedaży z nazwami klientów
LEFT JOIN	Wszystkie rekordy z lewej tabeli oraz dopasowania z prawej	Którzy klienci nie mają zamówień?	Lista kontaktów do reaktywacji
RIGHT JOIN	Wszystkie rekordy z prawej tabeli oraz dopasowania z lewej	Które produkty nie mają sprzedaży?	Kontrola katalogu produktów

\n\n

Aliasowanie tabel w złożonych kwerendach

\n

Gdy zapytanie obejmuje kilka tabel, pełne nazwy pól stają się długie. Możesz zastosować aliasy tabel:

\n

SELECT z.IDZamowienia,\n       z.DataZamowienia,\n       k.NazwaFirmy,\n       p.Kwota\nFROM (Klienci AS k\nINNER JOIN Zamowienia AS z ON k.IDKlienta = z.IDKlienta)\nLEFT JOIN Platnosci AS p ON z.IDZamowienia = p.IDZamowienia;

\n

Access często dodaje nawiasy przy wielu złączeniach. Nie usuwaj ich bez potrzeby, bo aparat bazy Access jest bardziej wymagający w tym obszarze niż niektóre serwery SQL. Jeżeli widok projektu potrafi otworzyć kwerendę i pokazać relacje poprawnie, to zwykle znak, że składnia JOIN jest akceptowana.

\n\n

Agregacja GROUP BY i HAVING: od rekordów do wskaźników

\n

Same listy rekordów rzadko wystarczają do decyzji. Właściciel małej firmy nie zawsze potrzebuje widzieć tysiąc pozycji sprzedaży. Częściej chce znać sumę sprzedaży według miesiąca, liczbę zamówień według statusu, średnią wartość koszyka albo klientów przekraczających określony próg obrotu. Do tego służą kwerendy agregujące, czyli SELECT z GROUP BY.

\n

Przykład: liczba zamówień według statusu:

\n

SELECT Status, Count(*) AS LiczbaZamowien\nFROM Zamowienia\nGROUP BY Status\nORDER BY Count(*) DESC;

\n

Przykład: wartość sprzedaży według klienta, jeśli w pozycjach zamówienia masz ilość i cenę jednostkową:

\n

SELECT k.NazwaFirmy,\n       Sum(pz.Ilosc * pz.CenaJednostkowa) AS WartoscSprzedazy\nFROM (Klienci AS k\nINNER JOIN Zamowienia AS z ON k.IDKlienta = z.IDKlienta)\nINNER JOIN PozycjeZamowien AS pz ON z.IDZamowienia = pz.IDZamowienia\nGROUP BY k.NazwaFirmy\nORDER BY Sum(pz.Ilosc * pz.CenaJednostkowa) DESC;

\n

Microsoft opisuje zliczanie danych przy użyciu kwerendy, w tym funkcje agregujące, w osobnym artykule: zliczanie danych przy użyciu kwerendy. Warto do niego wrócić, gdy zaczynasz budować raporty o liczbie rekordów, średnich lub sumach.

\n\n

WHERE a HAVING: różnica, która decyduje o wyniku

\n

WHERE filtruje rekordy przed grupowaniem. HAVING filtruje grupy po agregacji. Ta różnica jest bardzo ważna. Jeżeli chcesz policzyć sprzedaż tylko z 2026 roku, używasz WHERE przed GROUP BY:

\n

SELECT k.NazwaFirmy,\n       Sum(pz.Ilosc * pz.CenaJednostkowa) AS WartoscSprzedazy\nFROM (Klienci AS k\nINNER JOIN Zamowienia AS z ON k.IDKlienta = z.IDKlienta)\nINNER JOIN PozycjeZamowien AS pz ON z.IDZamowienia = pz.IDZamowienia\nWHERE z.DataZamowienia >= #2026-01-01#\n  AND z.DataZamowienia < #2027-01-01#\nGROUP BY k.NazwaFirmy;

\n

Jeżeli chcesz pokazać tylko klientów, których sprzedaż przekroczyła 10000 zł, używasz HAVING po GROUP BY:

\n

SELECT k.NazwaFirmy,\n       Sum(pz.Ilosc * pz.CenaJednostkowa) AS WartoscSprzedazy\nFROM (Klienci AS k\nINNER JOIN Zamowienia AS z ON k.IDKlienta = z.IDKlienta)\nINNER JOIN PozycjeZamowien AS pz ON z.IDZamowienia = pz.IDZamowienia\nGROUP BY k.NazwaFirmy\nHAVING Sum(pz.Ilosc * pz.CenaJednostkowa) > 10000;

\n

W praktyce często używasz obu klauzul naraz: WHERE ogranicza zakres dat, statusów lub regionów, a HAVING zostawia tylko grupy spełniające próg biznesowy.

\n\n

Typowe funkcje agregujące

\n

Access udostępnia funkcje agregujące, takie jak Count, Sum, Avg, Min i Max. Count(*) liczy rekordy, a Count(NazwaPola) liczy rekordy z niepustą wartością w danym polu. Ta różnica ma znaczenie, gdy pole może być Null. Jeżeli liczysz wszystkie zamówienia, użyj Count(*). Jeżeli liczysz tylko rekordy z datą zapłaty, użyj Count(DataZaplaty).

\n

Przykład kontroli płatności:

\n

SELECT IDKlienta,\n       Count(*) AS LiczbaPlatnosci,\n       Count(DataZaplaty) AS LiczbaZaplaconych,\n       Sum(Kwota) AS SumaNaleznosci\nFROM Platnosci\nGROUP BY IDKlienta;

\n

Taka kwerenda pokaże różnicę między liczbą wszystkich płatności a liczbą płatności faktycznie opłaconych. W raporcie możesz później dodać pole obliczeniowe wskazujące liczbę płatności otwartych.

\n\n\n\n\n\n\n\n\n\n\n\n\n

Klauzula lub funkcja	Rola w kwerendzie	Najczęstszy błąd	Dobra praktyka
WHERE	Filtruje rekordy przed grupowaniem	Próba filtrowania sumy, która jeszcze nie istnieje	Używaj do dat, statusów, regionów i pól źródłowych
GROUP BY	Tworzy grupy rekordów	Dodanie pola do SELECT bez agregacji i bez GROUP BY	Grupuj tylko po wymiarach analizy, na przykład klient, miesiąc, region
HAVING	Filtruje grupy po obliczeniu agregacji	Używanie HAVING zamiast prostego WHERE	Stosuj do progów typu suma większa niż 10000
ORDER BY	Sortuje wynik końcowy	Zakładanie, że wynik ma stałą kolejność bez sortowania	Zawsze ustaw sortowanie w raportach i eksportach
Count, Sum, Avg	Liczą rekordy, sumy i średnie	Mylenie Count(*) z Count(Pole)	Ustal, czy chcesz liczyć wszystkie rekordy, czy tylko niepuste wartości

\n\n

Kwerendy parametryczne: pytanie o dane wejściowe

\n

Kwerenda parametryczna prosi użytkownika o wartość w chwili uruchomienia. To wygodne, gdy chcesz mieć jedną kwerendę do wielu podobnych analiz. Zamiast tworzyć osobne kwerendy dla każdego miasta, klienta albo zakresu dat, zapisujesz parametr w nawiasach kwadratowych. Access pokaże okno dialogowe z tekstem parametru.

\n

SELECT IDZamowienia, IDKlienta, DataZamowienia, Status\nFROM Zamowienia\nWHERE DataZamowienia BETWEEN [Podaj datę od:] AND [Podaj datę do:]\nORDER BY DataZamowienia;

\n

Po uruchomieniu kwerendy użytkownik wpisuje daty, a Access zwraca wynik dla wybranego zakresu. Możesz też pytać o miasto:

\n

SELECT NazwaFirmy, Miasto, Region\nFROM Klienci\nWHERE Miasto = [Podaj miasto:];

\n

Parametry są dobre dla prostych raportów, ale przy częstym użyciu lepszy może być formularz z polami wyboru. Formularz daje większą kontrolę: możesz zastosować listę rozwijaną klientów, kalendarz dla dat, przycisk uruchamiający raport i walidację. Parametr tekstowy jest szybki, lecz podatny na literówki.

\n\n

Parametry a typy danych

\n

Przy parametrach zwracaj uwagę na typ danych. Jeżeli Access nie rozpozna parametru jako daty albo liczby, wynik może być błędny albo kwerenda poprosi o parametr ponownie. W widoku projektu można określić parametry kwerendy i ich typy. Dla dat wybieraj typ Data/Godzina, dla identyfikatorów liczbowych odpowiedni typ liczbowy, a dla nazw tekst. To szczególnie ważne, gdy kwerenda jest źródłem raportu, formularza albo kolejnej kwerendy.

\n

Unikaj parametrów w kwerendach, które mają być używane przez inne kwerendy automatycznie, chyba że dokładnie kontrolujesz uruchamianie. Łańcuch kilku kwerend z parametrami może prowadzić do nieczytelnych okien dialogowych. W takich scenariuszach lepiej użyć formularza lub tabeli ustawień raportu.

\n\n

Kwerendy krzyżowe CROSSTAB: kompaktowe zestawienia podobne do tabeli przestawnej

\n

Kwerenda krzyżowa w Access przekształca dane podsumowujące w układ z nagłówkami wierszy i kolumn. To przydatne, gdy chcesz zobaczyć sprzedaż według regionu i miesiąca, liczbę zgłoszeń według statusu i pracownika albo koszty według kategorii i kwartału. Microsoft opisuje kwerendy krzyżowe jako sposób zwiększania czytelności danych podsumowania, ponieważ grupują dane pionowo i poziomo: zwiększanie czytelności danych podsumowania za pomocą kwerendy krzyżowej.

\n

Przykład sprzedaży według regionu i miesiąca może wyglądać tak:

\n

TRANSFORM Sum(pz.Ilosc * pz.CenaJednostkowa) AS Sprzedaz\nSELECT k.Region\nFROM (Klienci AS k\nINNER JOIN Zamowienia AS z ON k.IDKlienta = z.IDKlienta)\nINNER JOIN PozycjeZamowien AS pz ON z.IDZamowienia = pz.IDZamowienia\nGROUP BY k.Region\nPIVOT Format(z.DataZamowienia, 'yyyy-mm');

\n

Wynik będzie miał regiony w wierszach i miesiące w kolumnach. Dla szybkiego przeglądu to bardzo wygodne. Jeżeli jednak zakres miesięcy stale się zmienia, kolumny w wyniku też będą się zmieniać. To może utrudnić budowanie raportu o stałym układzie. W takim przypadku warto ograniczyć kolumny przez listę wartości PIVOT albo przygotować raport w Excelu po eksporcie danych.

\n\n

Kwerenda krzyżowa a tabela przestawna w Excelu

\n

Kwerenda krzyżowa jest dobrym rozwiązaniem, gdy wynik ma powstać w Accessie i być częścią raportu lub formularza. Tabela przestawna w Excelu jest lepsza, gdy użytkownik chce interaktywnie przeciągać pola, filtrować widoki i zmieniać układ bez modyfikowania kwerendy. Dlatego praktyczny proces w firmie często wygląda tak: Access przechowuje i oczyszcza dane, kwerenda wybierająca lub krzyżowa przygotowuje zestaw, a Excel służy do końcowej prezentacji.

\n

Jeśli wiele osób analizuje dane w Excelu, ale źródło powinno być spójne, warto rozważyć zestaw Office obejmujący oba narzędzia. W ofercie kategorii Klucze Office można porównać edycje pakietu pod kątem pracy z Excelem, Accessem i pozostałymi aplikacjami biurowymi. Dla osoby zarządzającej bazą kluczowe jest, aby używana edycja zawierała Access, a dla pozostałych stanowisk istotna może być głównie wygodna praca z raportami w Excelu.

\n\n

Kwerendy akcji: UPDATE, INSERT INTO, DELETE i SELECT INTO

\n

Kwerendy akcji zmieniają dane albo strukturę wynikową. Są bardzo użyteczne, ale wymagają większej ostrożności niż SELECT. Najważniejsza zasada: zanim wykonasz kwerendę aktualizującą, usuwającą albo dołączającą, przygotuj kwerendę wybierającą z tym samym warunkiem i sprawdź rekordy. Dodatkowo wykonaj kopię bazy, zwłaszcza gdy pracujesz na pliku produkcyjnym. W Accessie cofnięcie dużej kwerendy akcji nie zawsze jest realnym planem awaryjnym.

\n

Do kwerend akcji należą między innymi UPDATE, INSERT INTO, DELETE oraz SELECT INTO. Można je tworzyć z poziomu widoku projektu, wybierając typ kwerendy, ale przy bardziej precyzyjnych operacjach warto rozumieć SQL.

\n\n

UPDATE: aktualizowanie rekordów

\n

UPDATE zmienia wartości w istniejących rekordach. Przykład: podniesienie rabatu dla klientów z segmentu partnerskiego:

\n

UPDATE Klienci\nSET RabatDomyslny = 0.10\nWHERE Segment = 'Partner';

\n

Przed wykonaniem sprawdź SELECT:

\n

SELECT IDKlienta, NazwaFirmy, Segment, RabatDomyslny\nFROM Klienci\nWHERE Segment = 'Partner';

\n

Jeżeli wynik SELECT obejmuje właściwe rekordy, dopiero wtedy uruchamiaj UPDATE. Dla operacji masowych warto zapisać datę zmiany, identyfikator użytkownika albo notatkę w tabeli historii, jeśli baza ma taką strukturę.

\n\n

INSERT INTO: dołączanie danych

\n

INSERT INTO dodaje nowe rekordy do tabeli. W Accessie często używa się go do przenoszenia danych z tabeli importowej do tabeli właściwej. Załóżmy, że importujesz listę nowych klientów z Excela do tabeli ImportKlienci, a potem chcesz dopisać ich do tabeli Klienci:

\n

INSERT INTO Klienci (NazwaFirmy, NIP, Miasto, Region)\nSELECT NazwaFirmy, NIP, Miasto, Region\nFROM ImportKlienci\nWHERE NIP IS NOT NULL;

\n

Przed takim dołączeniem sprawdź duplikaty. Jeżeli NIP ma być unikatowy, przygotuj kwerendę wykrywającą NIP istniejący już w tabeli głównej:

\n

SELECT i.NIP, i.NazwaFirmy\nFROM ImportKlienci AS i\nINNER JOIN Klienci AS k ON i.NIP = k.NIP;

\n

Jeżeli wynik nie jest pusty, nie dołączaj danych bez decyzji, co zrobić z duplikatami. Możesz je pominąć, zaktualizować istniejące rekordy albo przekazać do ręcznej kontroli.

\n\n

DELETE: usuwanie rekordów

\n

DELETE usuwa rekordy. To najbardziej ryzykowny typ kwerendy akcji. Przykład usunięcia pustych rekordów importowych:

\n

DELETE FROM ImportKlienci\nWHERE NIP IS NULL\n  AND NazwaFirmy IS NULL;

\n

Najpierw uruchom:

\n

SELECT *\nFROM ImportKlienci\nWHERE NIP IS NULL\n  AND NazwaFirmy IS NULL;

\n

Nie używaj DELETE do archiwizacji danych, jeżeli firma może ich jeszcze potrzebować. Lepiej dodać pole Aktywny, DataArchiwizacji albo przenieść rekordy do tabeli archiwalnej przez INSERT INTO, a dopiero po kontroli usuwać ze źródła. W małej firmie historia kontaktu z klientem, stary cennik lub dawne zamówienie często okazują się potrzebne przy reklamacji albo analizie sezonowości.

\n\n

SELECT INTO: tworzenie tabeli z wyniku

\n

SELECT INTO tworzy nową tabelę na podstawie wyniku kwerendy. To przydatne do snapshotów, archiwów i przygotowania danych do jednorazowej analizy. Przykład: zapis sprzedaży za 2026 rok do nowej tabeli:

\n

SELECT z.IDZamowienia,\n       z.DataZamowienia,\n       k.NazwaFirmy,\n       pz.IDProduktu,\n       pz.Ilosc,\n       pz.CenaJednostkowa\nINTO ArchiwumSprzedaz2026\nFROM (Klienci AS k\nINNER JOIN Zamowienia AS z ON k.IDKlienta = z.IDKlienta)\nINNER JOIN PozycjeZamowien AS pz ON z.IDZamowienia = pz.IDZamowienia\nWHERE z.DataZamowienia >= #2026-01-01#\n  AND z.DataZamowienia < #2027-01-01#;

\n

Nowa tabela nie dziedziczy automatycznie wszystkich właściwości relacji, indeksów i reguł biznesowych tak jak pełny projekt tabeli. Traktuj ją jako wynik roboczy lub archiwalny, nie jako zamiennik dobrze zaprojektowanej tabeli produkcyjnej.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Typ kwerendy	Składnia SQL	Czy zmienia dane?	Przykład użycia
Wybierająca	SELECT ... FROM ... WHERE ...	Nie	Lista zamówień z wybranego miesiąca
Parametryczna	SELECT z parametrem w nawiasach kwadratowych	Nie, jeśli oparta na SELECT	Raport dla dat wpisanych przez użytkownika
Krzyżowa	TRANSFORM ... SELECT ... PIVOT ...	Nie	Sprzedaż według regionu i miesiąca
Aktualizująca	UPDATE ... SET ... WHERE ...	Tak	Masowa zmiana statusu lub rabatu
Dołączająca	INSERT INTO ... SELECT ...	Tak	Dopisanie danych z tabeli importowej
Usuwająca	DELETE FROM ... WHERE ...	Tak	Usunięcie pustych rekordów technicznych
Tworząca tabelę	SELECT ... INTO ... FROM ...	Tworzy nową tabelę	Snapshot danych do archiwum lub kontroli

\n\n

Funkcje DSum, DCount i DLookup w praktyce

\n

Access ma grupę funkcji nazywanych funkcjami agregującymi domeny. Działają one na wskazanym zestawie rekordów, czyli domenie, i mogą być używane w kwerendach, formularzach, raportach, makrach oraz VBA. Najczęściej spotkasz DSum, DCount i DLookup. Są wygodne, ale trzeba stosować je świadomie, bo przy dużych zbiorach i w wielu wierszach mogą być wolniejsze niż JOIN albo GROUP BY.

\n

DSum sumuje wartości w domenie. Microsoft dokumentuje składnię i zastosowanie tej funkcji tutaj: funkcja DSum. Przykład w kwerendzie klientów:

\n

SELECT IDKlienta,\n       NazwaFirmy,\n       DSum("[Kwota]", "Platnosci", "[IDKlienta]=" & [IDKlienta]) AS SumaPlatnosci\nFROM Klienci;

\n

Taki zapis pobiera dla każdego klienta sumę płatności z tabeli Platnosci. Przy małej bazie jest czytelny i szybki do napisania. Przy większej liczbie klientów lepsza może być kwerenda agregująca płatności po IDKlienta i połączenie jej z tabelą klientów przez LEFT JOIN.

\n\n

DCount: liczenie rekordów w domenie

\n

DCount liczy rekordy spełniające kryteria. Microsoft opisuje funkcję w dokumentacji: funkcja DCount. Przykład: liczba otwartych zamówień klienta:

\n

SELECT IDKlienta,\n       NazwaFirmy,\n       DCount("*", "Zamowienia", "[IDKlienta]=" & [IDKlienta] & " AND [Status]='W realizacji'") AS OtwarteZamowienia\nFROM Klienci;

\n

W kryteriach tekstowych pamiętaj o apostrofach wokół wartości tekstowej. Dla dat używaj znaków #. Dla liczb nie dodawaj apostrofów. Błędy w składaniu kryteriów są najczęstszą przyczyną niepoprawnych wyników funkcji domenowych.

\n\n

DLookup: pobieranie pojedynczej wartości

\n

DLookup zwraca wartość jednego pola z pierwszego rekordu spełniającego kryteria. Dokumentacja Microsoftu podaje składnię i przykłady użycia: funkcja DLookup. Przykład: pobranie domyślnego rabatu klienta do kwerendy zamówień:

\n

SELECT IDZamowienia,\n       IDKlienta,\n       DLookup("[RabatDomyslny]", "Klienci", "[IDKlienta]=" & [IDKlienta]) AS RabatKlienta\nFROM Zamowienia;

\n

W wielu przypadkach JOIN będzie lepszy:

\n

SELECT z.IDZamowienia,\n       z.IDKlienta,\n       k.RabatDomyslny AS RabatKlienta\nFROM Zamowienia AS z\nINNER JOIN Klienci AS k ON z.IDKlienta = k.IDKlienta;

\n

JOIN jest zwykle bardziej przejrzysty, gdy pobierasz dane z tabeli powiązanej relacją. DLookup zostaw dla sytuacji, w których potrzebujesz pojedynczej wartości pomocniczej w formularzu, raporcie albo prostym wyrażeniu.

\n\n

Podzapytania: filtr wewnątrz filtra

\n

Podzapytanie to zapytanie umieszczone wewnątrz innego zapytania. Pozwala wyrazić warunki, które trudno zapisać samym JOIN lub prostym WHERE. Typowe zastosowania to znalezienie rekordów z wartością większą od średniej, klientów mających zamówienia w określonej grupie albo produktów, które nigdy nie zostały sprzedane.

\n

Przykład: zamówienia o wartości większej niż średnia wartość zamówienia. Najpierw warto mieć kwerendę pomocniczą qWartosciZamowien:

\n

SELECT IDZamowienia,\n       Sum(Ilosc * CenaJednostkowa) AS WartoscZamowienia\nFROM PozycjeZamowien\nGROUP BY IDZamowienia;

\n

Następnie możesz użyć podzapytania:

\n

SELECT IDZamowienia, WartoscZamowienia\nFROM qWartosciZamowien\nWHERE WartoscZamowienia > (SELECT Avg(WartoscZamowienia) FROM qWartosciZamowien);

\n

To czytelny sposób na znalezienie ponadprzeciętnych zamówień. Można go wykorzystać do analizy klientów premium, wyjątkowo dużych transakcji albo anomalii wymagających kontroli.

\n\n

IN i NOT IN z podzapytaniem

\n

Podzapytania często występują z IN albo NOT IN. Przykład: klienci, którzy złożyli zamówienie w 2026 roku:

\n

SELECT IDKlienta, NazwaFirmy\nFROM Klienci\nWHERE IDKlienta IN\n  (SELECT IDKlienta\n   FROM Zamowienia\n   WHERE DataZamowienia >= #2026-01-01#\n     AND DataZamowienia < #2027-01-01#);

\n

Klienci bez zamówienia w 2026 roku:

\n

SELECT IDKlienta, NazwaFirmy\nFROM Klienci\nWHERE IDKlienta NOT IN\n  (SELECT IDKlienta\n   FROM Zamowienia\n   WHERE DataZamowienia >= #2026-01-01#\n     AND DataZamowienia < #2027-01-01#);

\n

Przy NOT IN uważaj na wartości Null w podzapytaniu. Jeżeli podzapytanie może zwrócić Null, wynik może być zaskakujący. Wtedy dopisz warunek IDKlienta IS NOT NULL w podzapytaniu albo użyj LEFT JOIN z filtrem IS NULL, który jest często bardziej przewidywalny.

\n\n

Eksport wyników do Excela i praca między aplikacjami Office

\n

Access jest bardzo dobry do przechowywania, łączenia i filtrowania danych, ale Excel pozostaje wygodny do prezentacji, wykresów, tabel przestawnych i szybkich analiz ad hoc. Microsoft w dokumentacji podkreśla, że przy eksporcie Access tworzy kopię wybranych danych w pliku możliwym do otwarcia w Excelu: eksportowanie danych do programu Excel. To ważne: eksport nie jest tym samym co automatyczna dwukierunkowa synchronizacja.

\n

Najbezpieczniejszy proces wygląda tak: przygotuj kwerendę, sprawdź wynik, ustaw czytelne aliasy kolumn, zapisz kwerendę, a dopiero potem eksportuj ją do Excela. Dzięki temu arkusz nie zawiera technicznych pól, których odbiorca nie rozumie, ani rekordów spoza zakresu. Jeżeli wynik będzie cyklicznie wysyłany do zarządu, księgowości lub handlowców, zapisz specyfikację eksportu albo przygotuj prosty formularz z przyciskiem.

\n\n

Jak przygotować kwerendę do eksportu

\n

Przed eksportem zadbaj o pięć rzeczy. Po pierwsze, ustaw jednoznaczne nazwy kolumn przez aliasy. Zamiast Expr1001 użyj WartoscSprzedazy. Po drugie, usuń pola techniczne, których odbiorca nie potrzebuje. Po trzecie, ustaw ORDER BY, bo Excel otrzyma dane w kolejności wyniku. Po czwarte, sformatuj dane po stronie Excela dopiero wtedy, gdy eksport jest stabilny. Po piąte, nie eksportuj bezpośrednio tabeli produkcyjnej, jeśli odbiorca potrzebuje tylko fragmentu danych.

\n

Przykład kwerendy eksportowej:

\n

SELECT k.NazwaFirmy AS Klient,\n       k.NIP,\n       z.DataZamowienia AS Data,\n       z.Status,\n       Sum(pz.Ilosc * pz.CenaJednostkowa) AS WartoscZamowienia\nFROM (Klienci AS k\nINNER JOIN Zamowienia AS z ON k.IDKlienta = z.IDKlienta)\nINNER JOIN PozycjeZamowien AS pz ON z.IDZamowienia = pz.IDZamowienia\nWHERE z.DataZamowienia >= [Data od:]\n  AND z.DataZamowienia <= [Data do:]\nGROUP BY k.NazwaFirmy, k.NIP, z.DataZamowienia, z.Status\nORDER BY z.DataZamowienia, k.NazwaFirmy;

\n

Po uruchomieniu kwerendy możesz użyć karty Dane zewnętrzne i eksportu do Excela. Jeśli później chcesz wkleić fragment wyniku ręcznie, standardowe skróty Ctrl+C i Ctrl+V też zadziałają, ale przy powtarzalnych raportach lepszy jest zapisany eksport.

\n\n

Access i Excel w jednym procesie firmowym

\n

W małej firmie bardzo dobrze sprawdza się podział ról: Access jest miejscem prawdy dla danych operacyjnych, a Excel narzędziem analizy i prezentacji. Przykład: recepcja lub sprzedaż wprowadza zamówienia przez formularz Access, właściciel eksportuje miesięczne wyniki do Excela, a księgowość otrzymuje zestawienie płatności. W takim układzie warto ujednolicić wersje pakietu Office na stanowiskach, aby uniknąć problemów z formatami i funkcjami. Dla stanowisk pracujących głównie z dokumentami i arkuszami można rozważyć Microsoft Office 2024 Standard, natomiast stanowisko utrzymujące bazę Access powinno korzystać z edycji zawierającej Access.

\n

Jeżeli firma korzysta z subskrypcji, alternatywą mogą być plany z rodziny Microsoft 365. Wybór między licencją wieczystą Office a subskrypcją zależy od sposobu pracy, liczby stanowisk, potrzeby aktualizacji i integracji z chmurą. Niezależnie od modelu, sama praktyka pracy z kwerendami pozostaje podobna: najpierw poprawny model danych, potem kwerendy, na końcu raporty i eksporty.

\n\n

Dobre praktyki projektowania kwerend dla małej firmy

\n

Kwerendy są skuteczne tylko wtedy, gdy baza ma sensowną strukturę. Jeżeli w jednej tabeli trzymasz klienta, zamówienie, produkt, płatność i notatkę, szybko napotkasz duplikaty, puste pola i trudne warunki. Warto zacząć od normalizacji: osobna tabela klientów, osobna tabela zamówień, osobna tabela pozycji, osobna tabela produktów i osobna tabela płatności. Każda tabela powinna mieć klucz podstawowy, a relacje powinny używać stabilnych identyfikatorów, nie nazw tekstowych.

\n

Drugą praktyką jest indeksowanie pól używanych do łączenia i filtrowania. Pola takie jak IDKlienta, IDZamowienia, NIP, DataZamowienia i Status często pojawiają się w JOIN, WHERE i ORDER BY. Dobrze dobrane indeksy przyspieszają kwerendy, szczególnie gdy baza rośnie. Nie indeksuj jednak bezmyślnie każdego pola, bo indeksy też mają koszt przy zapisie danych.

\n

Trzecią praktyką jest oddzielanie kwerend roboczych od raportowych. Kwerenda robocza może mieć techniczne pola i służyć jako etap pośredni. Kwerenda raportowa powinna mieć czytelne aliasy, stabilne sortowanie i tylko te kolumny, których potrzebuje odbiorca. Jeżeli raport miesięczny ma trafiać do Excela, nazwij kwerendę wprost, na przykład qEksportRaportMiesiecznySprzedazy.

\n\n

Testowanie kwerend akcji

\n

Kwerendy akcji zawsze testuj na kopii lub przez SELECT. Dobry schemat pracy wygląda tak: zapisujesz warunek WHERE, uruchamiasz SELECT, porównujesz liczbę rekordów z oczekiwaniem, dopiero potem zmieniasz typ kwerendy na UPDATE, DELETE albo INSERT INTO. Jeżeli kwerenda ma dotknąć wielu rekordów, zapisz przed zmianą kopię pliku bazy. To proste zabezpieczenie, które może oszczędzić wiele godzin odtwarzania danych.

\n

Przy operacjach cyklicznych rozważ tabelę logów. Może zawierać datę wykonania, nazwę operacji, liczbę rekordów i użytkownika. Nawet prosty log w Accessie pomaga wyjaśnić, dlaczego statusy zamówień zmieniły się danego dnia albo kto wykonał import nowych klientów.

\n\n

Nazwy pól i unikanie problemów składniowych

\n

Unikaj spacji i znaków specjalnych w nazwach tabel oraz pól. Access pozwala na nazwy typu Data zamówienia, ale potem musisz używać nawiasów kwadratowych: [Data zamówienia]. W większej bazie wygodniejsze są nazwy DataZamowienia, IDKlienta i KwotaNetto. Nie używaj słów zastrzeżonych jako nazw pól, na przykład Date, Name albo Value. Jeżeli przejmujesz bazę z takimi nazwami, konsekwentnie stosuj nawiasy kwadratowe.

\n

Warto też rozróżniać dane źródłowe od danych wyliczanych. W tabeli pozycji zamówienia przechowuj ilość i cenę jednostkową, a wartość pozycji licz w kwerendzie jako Ilosc * CenaJednostkowa, chyba że firma ma szczególny powód do przechowywania wartości historycznej. Jeżeli cena może się zmieniać, w pozycji zamówienia zapisuj cenę z momentu sprzedaży, nie pobieraj jej za każdym razem z aktualnej tabeli produktów.

\n\n

Bezpieczeństwo i podział pracy

\n

Access w małej firmie często działa jako plik współdzielony. Dobrą praktyką jest rozdzielenie bazy na część z tabelami i część z formularzami, kwerendami oraz raportami. Użytkownicy pracują na kopiach front-endu, a dane są w jednym back-endzie. Taki układ zmniejsza ryzyko konfliktów przy zmianach formularzy i kwerend. Nie zastępuje pełnego systemu serwerowego, ale jest wyraźnie lepszy niż jeden plik edytowany przez wszystkich.

\n

Jeżeli baza zaczyna obsługiwać krytyczne procesy, zaplanuj kopie zapasowe, procedurę kompaktowania i naprawy oraz reguły dostępu. Kwerendy usuwające i aktualizujące powinny być dostępne tylko dla osób, które rozumieją ich skutki. Dla pozostałych użytkowników przygotuj formularze i raporty, które ograniczają możliwość przypadkowego uszkodzenia danych.

\n\n

Najczęstsze scenariusze analityczne w Access

\n

Teoria SQL jest potrzebna, ale najłatwiej uczyć się kwerend przez konkretne pytania biznesowe. Poniżej znajdziesz kilka scenariuszy, które często pojawiają się w małej firmie. Każdy można rozbudować o parametry, formularze i eksport do Excela.

\n\n

Lista przeterminowanych płatności

\n

SELECT k.NazwaFirmy,\n       p.IDPlatnosci,\n       p.TerminPlatnosci,\n       p.Kwota\nFROM Klienci AS k\nINNER JOIN Platnosci AS p ON k.IDKlienta = p.IDKlienta\nWHERE p.DataZaplaty IS NULL\n  AND p.TerminPlatnosci < Date()\nORDER BY p.TerminPlatnosci ASC;

\n

Ta kwerenda zwraca niezapłacone płatności z terminem wcześniejszym niż bieżąca data. Możesz dodać parametr dla minimalnej kwoty, aby handlowiec skupiał się na większych zaległościach.

\n\n

Klienci bez aktywności od 90 dni

\n

SELECT k.IDKlienta, k.NazwaFirmy, Max(z.DataZamowienia) AS OstatnieZamowienie\nFROM Klienci AS k\nLEFT JOIN Zamowienia AS z ON k.IDKlienta = z.IDKlienta\nGROUP BY k.IDKlienta, k.NazwaFirmy\nHAVING Max(z.DataZamowienia) < DateAdd('d', -90, Date())\n    OR Max(z.DataZamowienia) IS NULL;

\n

To kwerenda dla sprzedaży lub obsługi klienta. Pokazuje klientów, którzy dawno nie złożyli zamówienia albo nie mają żadnego zamówienia. Możesz eksportować wynik do Excela, dodać kolumnę z opiekunem i rozdzielić zadania kontaktu.

\n\n

Produkty poniżej minimalnego stanu

\n

SELECT IDProduktu, NazwaProduktu, StanMagazynowy, StanMinimalny\nFROM Produkty\nWHERE StanMagazynowy <= StanMinimalny\nORDER BY StanMagazynowy ASC;

\n

Jeżeli Access służy do lekkiej obsługi magazynu, taka kwerenda może być podstawą listy zakupowej. W bardziej zaawansowanej wersji odejmujesz rezerwacje z otwartych zamówień i dodajesz dostawy w drodze.

\n\n

Sprzedaż według opiekuna

\n

SELECT z.IDOpiekuna,\n       Count(DISTINCT z.IDZamowienia) AS LiczbaZamowien,\n       Sum(pz.Ilosc * pz.CenaJednostkowa) AS Sprzedaz\nFROM Zamowienia AS z\nINNER JOIN PozycjeZamowien AS pz ON z.IDZamowienia = pz.IDZamowienia\nWHERE z.DataZamowienia >= [Data od:]\n  AND z.DataZamowienia <= [Data do:]\nGROUP BY z.IDOpiekuna\nORDER BY Sum(pz.Ilosc * pz.CenaJednostkowa) DESC;

\n

Jeżeli Access nie akceptuje Count(DISTINCT ...) w Twojej wersji lub składni, przygotuj najpierw kwerendę pomocniczą z unikatowymi zamówieniami, a potem policz je w kolejnym kroku. To typowy przykład sytuacji, w której podział logiki na dwie kwerendy jest prostszy niż forsowanie jednego zapytania.

\n\n

FAQ: kwerendy Access i SQL

\n\n\n

Podsumowanie

\n

Kwerendy Access pozwalają przejść od przechowywania danych do realnej analizy i automatyzacji pracy. Dobrze zaprojektowane SELECT, JOIN, WHERE, GROUP BY i HAVING potrafią zastąpić godziny ręcznego filtrowania w arkuszach. Kwerendy akcji przyspieszają importy, aktualizacje i archiwizację, ale wymagają testowania oraz kopii bezpieczeństwa. Funkcje DSum, DCount i DLookup są wygodne, gdy używa się ich w odpowiednim miejscu, a eksport do Excela domyka proces raportowania dla osób, które wolą analizować dane w arkuszu.

\n

\n
• Zaczynaj od kwerend wybierających SELECT i dopiero po kontroli przechodź do UPDATE, DELETE lub INSERT INTO.
\n
• Używaj INNER JOIN do rekordów z dopasowaniem, LEFT JOIN do wykrywania braków i luk w danych.
\n
• Filtruj rekordy przez WHERE, grupuj przez GROUP BY, a zagregowane wyniki ograniczaj przez HAVING.
\n
• Stosuj parametry i formularze, gdy użytkownik ma wybierać zakres dat, klienta, miasto lub status.
\n
• Przy raportach cyklicznych nadawaj kwerendom czytelne nazwy, aliasy kolumn i stabilne sortowanie.
\n
• Eksportuj do Excela gotowy wynik kwerendy, a nie surową tabelę produkcyjną.
\n
• Dla małej firmy traktuj Access jako uporządkowane źródło danych, a Excel jako wygodną warstwę prezentacji i dalszej analizy.
\n

\n\n