Filtry w Raport Studio — każdy typ na przykładach (PostgreSQL i MSSQL)

Praktyczny katalog przykładów: jak zdefiniować każdy z jedenastu typów parametrów raportu, jak wstawić go do zapytania SQL i czym różni się składnia na wewnętrznej bazie Veloryn (PostgreSQL) od raportu na połączeniu integracyjnym (MSSQL, np. WAPRO). Podstawy modułu znajdziesz w kompletnym przewodniku Raport Studio — tutaj skupiamy się wyłącznie na filtrach.

1Trzy zasady wspólne dla wszystkich typów

Parametr = kod w SQL

Parametr zdefiniowany w zakładce Filtry i parametry wstawiasz do zapytania jako @kod — dokładnie ten kod, który wpisałeś w polu Kod parametru. Wartość jest podstawiana bezpiecznie (bind po stronie bazy, nie sklejanie tekstu) — działa to identycznie na PostgreSQL i na MSSQL. Parametr, którego @kod nie występuje w SQL, jest ignorowany: filtr będzie widoczny, ale nie zmieni wyniku.

Filtry niewymagane — zawsze w klauzuli [[ ... ]]

Fragment SQL ujęty w podwójne nawiasy kwadratowe znika z zapytania w całości, jeśli którykolwiek użyty w nim parametr nie ma wartości (ani wpisanej przez użytkownika, ani domyślnej). To podstawowy wzorzec filtra opcjonalnego — bez niego pusty parametr zostawi w SQL nieprawidłowy warunek:

WHERE f.data_wystawienia BETWEEN @zakres
  [[ AND f.status = @status ]]
  [[ AND f.contractor_id = @kontrahent ]]

Parametr z ustawioną Wartością domyślną nigdy nie „wygasi" klauzuli — liczy się wartość efektywna. Klauzule [[ ]] działają też w zapytaniach opcji list oraz w raportach na połączeniach zewnętrznych.

Dialekt SQL zależy od źródła danych

Raport na wewnętrznej bazie piszesz w dialekcie PostgreSQL. Raport na połączeniu integracyjnym z bazą MSSQL (np. WAPRO) piszesz w T-SQL — ale definicje parametrów, składnia @kod, klauzule [[ ]] i tokeny działają tak samo. Różnią się tylko funkcje SQL wokół parametru (np. daty, sklejanie tekstu) — stąd w tym artykule każdy typ ma dwa warianty przykładu.

2Ściąga: 11 typów parametrów

3Tekst

Wartość trafia do SQL jako zwykły napis. Najczęstsze użycie to szukanie po fragmencie — pamiętaj, że operator „bez rozróżniania wielkości liter" i sklejanie tekstu wyglądają w obu dialektach inaczej:

PostgreSQL (baza Veloryn):

SELECT numer, contractor_name, wartosc_netto
FROM sales.sales_invoices
WHERE tenant_id = {TENANT_ID}
  [[ AND contractor_name ILIKE '%' || @fraza || '%' ]]

MSSQL (np. WAPRO) — LIKE zwykle nie rozróżnia wielkości liter (decyduje ustawienie bazy), tekst skleja się plusem:

SELECT k.nazwa, k.nip, k.miejscowosc
FROM dbo.kontrahent k
WHERE 1 = 1
  [[ AND k.nazwa LIKE '%' + @fraza + '%' ]]

4Liczba całkowita i Liczba dziesiętna

Oba typy działają identycznie w SQL — różni je tylko walidacja w kontrolce (całkowita nie przyjmie ułamka). Typowe zastosowania: rok, próg kwotowy, minimalna ilość.

PostgreSQL — rok jako liczba całkowita, próg jako dziesiętna:

SELECT numer, data_wystawienia, wartosc_netto
FROM sales.sales_invoices
WHERE tenant_id = {TENANT_ID}
  AND EXTRACT(YEAR FROM data_wystawienia) = @rok
  [[ AND wartosc_netto >= @kwota_min ]]

MSSQL — funkcja YEAR() zamiast EXTRACT:

SELECT d.numer, d.data_dokumentu, d.wartosc_netto
FROM dbo.dokument_handlowy d
WHERE YEAR(d.data_dokumentu) = @rok
  [[ AND d.wartosc_netto >= @kwota_min ]]

5Data oraz Data i czas

Pojedyncza data najlepiej sprawdza się jako granica: „od dnia", „do dnia", „stan na dzień". Do pełnych przedziałów wygodniejszy jest typ Zakres dat.

PostgreSQL:

SELECT numer, data_wystawienia, wartosc_netto
FROM sales.sales_invoices
WHERE tenant_id = {TENANT_ID}
  AND data_wystawienia >= @data_od
  [[ AND data_wystawienia < (@data_do)::date + INTERVAL '1 day' ]]

MSSQL:

SELECT d.numer, d.data_dokumentu, d.wartosc_netto
FROM dbo.dokument_handlowy d
WHERE d.data_dokumentu >= @data_od
  [[ AND d.data_dokumentu < DATEADD(DAY, 1, @data_do) ]]

6Tak/Nie

Przełącznik logiczny. Najbardziej naturalny wzorzec to filtr „pokaż tylko…", w którym włączenie przełącznika zawęża wynik, a wyłączenie pokazuje wszystko:

PostgreSQL:

SELECT nazwa, is_active
FROM products.products
WHERE tenant_id = {TENANT_ID}
  [[ AND is_active = @tylko_aktywne ]]

MSSQL — kolumny logiczne to zwykle bit (0/1), zapis bez zmian:

SELECT a.nazwa, a.czy_aktywny
FROM dbo.artykul a
WHERE 1 = 1
  [[ AND a.czy_aktywny = @tylko_aktywne ]]

7Lista wyboru

Użytkownik wybiera jedną wartość z listy — do SQL trafia wartość opcji, użytkownik widzi etykietę. W SQL to zwykłe porównanie: kolumna = @status. Ciekawie robi się przy definiowaniu opcji.

Opcje statyczne

Jedna opcja na linię, w formacie wartość|Etykieta (separatorem jest pionowa kreska):

draft|Szkic
issued|Wystawiona
paid|Zapłacona
cancelled|Anulowana

Opcje z zapytania SQL

Zapytanie opcji powinno zwracać kolumny value (wartość do SQL) i label (etykieta). Lista jest ograniczona do 100 opcji, a fraza z wyszukiwarki kontrolki jest dostępna w zapytaniu jako @SEARCH (pusta fraza = wartość pusta — obsłuż ją przez coalesce).

PostgreSQL — słownik kategorii z wyszukiwarką:

SELECT id AS value, nazwa AS label
FROM products.product_categories
WHERE nazwa ILIKE '%' || coalesce((@SEARCH)::text, '') || '%'
ORDER BY nazwa

MSSQL — to samo w T-SQL. Zapytanie opcji wykonuje się na tej samej bazie co raport, więc raport na WAPRO pobiera opcje prosto z WAPRO:

SELECT k.id_kontrahenta AS value, k.nazwa AS label
FROM dbo.kontrahent k
WHERE k.nazwa LIKE '%' + COALESCE(@SEARCH, '') + '%'
ORDER BY k.nazwa

Kaskadowanie (lista zależna)

W polu Zależy od parametrów wskaż parametr nadrzędny, a w zapytaniu opcji użyj jego wartości jak zwykłego parametru. Dzięki [[ ]] lista działa też, zanim użytkownik wybierze nadrzędny:

SELECT id AS value, nazwa AS label
FROM products.product_categories
WHERE 1 = 1
  [[ AND parent_id = @kategoria ]]
ORDER BY nazwa

8Lista wielokrotna

Użytkownik zaznacza wiele wartości. W SQL piszesz kolumna IN @statusy — bez nawiasów. System sam rozwinie parametr do listy (wartość1, wartość2, …), każda wartość bindowana osobno. Definicja opcji (statyczne / SQL / @SEARCH / kaskadowanie) działa dokładnie jak w Liście wyboru.

PostgreSQL:

SELECT numer, status, wartosc_netto
FROM sales.sales_invoices
WHERE tenant_id = {TENANT_ID}
  [[ AND status IN @statusy ]]

MSSQL:

SELECT d.numer, d.typ_dokumentu, d.wartosc_netto
FROM dbo.dokument_handlowy d
WHERE 1 = 1
  [[ AND d.typ_dokumentu IN @typy ]]

9Miesiąc

Kontrolka wyboru miesiąca. Do SQL trafia zawsze pierwszy dzień wybranego miesiąca (np. „sierpień 2026" → 2026-08-01) — warunek pisz więc „na cały miesiąc":

PostgreSQL — najprościej przez date_trunc:

SELECT numer, data_wystawienia, wartosc_netto
FROM sales.sales_invoices
WHERE tenant_id = {TENANT_ID}
  AND date_trunc('month', data_wystawienia) = @miesiac

Na bardzo dużych tabelach szybszy jest zapis przedziałowy (pozwala użyć indeksu na kolumnie daty):

WHERE data_wystawienia >= @miesiac
  AND data_wystawienia < (@miesiac)::date + INTERVAL '1 month'

MSSQL — starsze wersje SQL Servera nie mają date_trunc, uniwersalny jest zapis przedziałowy z DATEADD:

SELECT d.numer, d.data_dokumentu, d.wartosc_netto
FROM dbo.dokument_handlowy d
WHERE d.data_dokumentu >= @miesiac
  AND d.data_dokumentu < DATEADD(MONTH, 1, @miesiac)

10Drzewo miesięcy + SQL zakresu danych

Rozbudowany wariant filtra miesiąca: użytkownik dostaje rozwijane drzewo rok → miesiące i jednym kliknięciem wybiera miesiąc. Nagłówek roku nie jest opcją — zawsze wybierasz jeden konkretny miesiąc (rok pokazuje tylko, ile miesięcy z danymi zawiera). Wartość i warunki SQL są identyczne jak w typie Miesiąc (§9): pierwszy dzień miesiąca, date_trunc na PostgreSQL, przedział z DATEADD na MSSQL.

Po co „SQL zakresu danych"

Domyślnie drzewo pokazuje 5 lat wstecz od dziś — także miesiące, w których nie ma żadnych danych. Pole SQL zakresu danych (opcjonalnie) w definicji parametru pozwala to ograniczyć: podajesz zapytanie zwracające jeden wiersz z pierwszym i ostatnim okresem, w którym są dane (kolumny min i max), a drzewo wyszarza miesiące spoza tego zakresu. Użytkownik od razu widzi, które okresy mają sens.

PostgreSQL — zakres z faktur (dane ograniczają się do Twojej organizacji automatycznie, warunku po tenancie nie dopisujesz):

SELECT MIN(data_wystawienia) AS min,
       MAX(data_wystawienia) AS max
FROM sales.sales_invoices

MSSQL — zakres z dokumentów handlowych WAPRO:

SELECT MIN(d.data_dokumentu) AS min,
       MAX(d.data_dokumentu) AS max
FROM dbo.dokument_handlowy d

11Zakres dat

Jedna kontrolka „od–do" z podręcznymi presetami (bieżący miesiąc, kwartał, rok…). W SQL używasz jednego placeholdera w stałej pozycji: kolumna BETWEEN @zakres — system sam rozwinie go do pary „data od AND data do". Nie piszesz osobnych parametrów @od/@do i nie rozdzielasz ich własnym AND.

PostgreSQL:

SELECT numer, data_wystawienia, wartosc_netto
FROM sales.sales_invoices
WHERE tenant_id = {TENANT_ID}
  AND data_wystawienia BETWEEN @zakres

MSSQL:

SELECT d.numer, d.data_dokumentu, d.wartosc_netto
FROM dbo.dokument_handlowy d
WHERE d.data_dokumentu BETWEEN @zakres

12Kompletny przykład — od definicji do SQL

SELECT p.nazwa            AS produkt,
       COUNT(*)           AS liczba_pozycji,
       SUM(i.wartosc_netto) AS sprzedaz_netto
FROM sales.invoice_items i
JOIN sales.sales_invoices f ON f.id = i.invoice_id
JOIN products.products p    ON p.id = i.product_id
WHERE f.tenant_id = {TENANT_ID}
  AND f.data_wystawienia >= @miesiac
  AND f.data_wystawienia < (@miesiac)::date + INTERVAL '1 month'
  [[ AND p.category_id IN @kategorie ]]
  [[ AND p.nazwa ILIKE '%' || @fraza || '%' ]]
GROUP BY p.nazwa
ORDER BY sprzedaz_netto DESC

SELECT a.nazwa               AS produkt,
       COUNT(*)              AS liczba_pozycji,
       SUM(p.wartosc_netto)  AS sprzedaz_netto
FROM dbo.pozycja_dokumentu p
JOIN dbo.dokument_handlowy d ON d.id_dokumentu = p.id_dokumentu
JOIN dbo.artykul a           ON a.id_artykulu = p.id_artykulu
WHERE d.data_dokumentu >= @miesiac
  AND d.data_dokumentu < DATEADD(MONTH, 1, @miesiac)
  [[ AND a.id_kategorii IN @kategorie ]]
  [[ AND a.nazwa LIKE '%' + @fraza + '%' ]]
GROUP BY a.nazwa
ORDER BY sprzedaz_netto DESC

13Najczęstsze błędy przy filtrach