Baza_widok_tabela to raport RDL dokumentujący jeden poziom głębiej niż raport Baza_widok - nie sam fakt istnienia widoku, ale konkretne kolumny, jakie system wygenerował dla niego automatycznie na podstawie zapytania SQL, wraz z mechanizmem transakcji adm_widok_kolumny.aspx odpowiedzialnym za ich utrzymanie.
Czym jest raport Baza_widok_tabela
Widok w StudioSystem to w praktyce zapytanie SQL plus konfiguracja jego prezentacji - ale sama konfiguracja prezentacji nie powstaje ręcznie, kolumna po kolumnie, jedna za drugą. Odpowiada za nią osobny mechanizm, opisany szczegółowo w transakcji adm_widok_kolumny.aspx. Raport Baza_widok_tabela eksportuje wynik działania tego mechanizmu - powiązanie między widokiem a wygenerowanymi dla niego kolumnami.
Podobnie jak pozostałe raporty z tej rodziny, plik jest w formacie RDL i edytuje się go w Microsoft Report Builder 3.x. Adresatem jest ponownie osoba techniczna - administrator albo programista analizujący, dlaczego dany widok pokazuje akurat taki, a nie inny zestaw kolumn.
Razem z raportem Baza_sql i raportem Baza_widok tworzy trzeci element tej samej rodziny dokumentacji technicznej - każdy z nich patrzy na tę samą bazę danych z innego poziomu szczegółowości. Baza_sql opisuje zapytania formularzy zapisu, Baza_widok - definicje samych widoków, a Baza_widok_tabela schodzi jeszcze niżej, do pojedynczej kolumny w konkretnym zestawieniu.
Mechanizm adm_widok_kolumny.aspx
Definicja widoku przechowywana jest w tabeli x_zestawienia, natomiast wygenerowane dla niego kolumny - w osobnej tabeli x_zestawienia_kolumny. Transakcja adm_widok_kolumny.aspx spina te dwie tabele: na starcie odczytuje parametr refno z żądania HTTP, identyfikujący konkretny widok, a jeśli parametr nie zostanie dostarczony, zwraca użytkownikowi komunikat błędu zamiast próbować zgadywać, o który widok chodzi.
Na podstawie zapytania SQL zapisanego dla wskazanego widoku system generuje strukturę kolumn i przekierowuje użytkownika do właściwej strony z gotowym zestawieniem. Cały proces jest zautomatyzowany - administrator nie definiuje kolumn ręcznie, tylko dostarcza zapytanie SQL, a resztę wykonuje mechanizm opisany w kolejnej sekcji.
Warto zaznaczyć, że sam parametr refno nie jest numerem kolumny ani numerem rekordu danych - to numer referencyjny wiersza w tabeli x_zestawienia, a więc identyfikator samego widoku, dla którego mechanizm ma odtworzyć lub zaktualizować strukturę kolumn. Ten sam schemat nazewnictwa parametru spotyka się zresztą w wielu innych transakcjach platformy - refno niemal zawsze oznacza „numer referencyjny rekordu, którego dotyczy operacja”, niezależnie od tego, czy chodzi o widok, dokument magazynowy czy kartotekę kontrahenta.
Jedno kliknięcie zamiast ręcznej konfiguracji
Administrator klika jedno polecenie w interfejsie, a system w tle odczytuje zapytanie, wykonuje je i buduje kolumny wyniku.
Kluczowe funkcje warstwy serwerowej
Logika transakcji podzielona jest na kilka funkcji, z których każda odpowiada za wąski, dobrze określony fragment procesu:
| Funkcja | Zadanie |
|---|---|
Page_Load | Odczytuje parametr refno, identyfikuje widok i przekierowuje do właściwej strony |
UtworzStrukture | Wykonuje zapytanie SQL widoku i generuje na jego podstawie kolumny |
CzyKolumnaIstnieje | Sprawdza w x_zestawienia_kolumny, czy dana kolumna już istnieje, unikając duplikatów |
PodstawZmienne | Podstawia zmienne sesyjne, np. @LOGIN i @MAIL, oraz bieżącą datę do zapytania |
Rozdzielenie odpowiedzialności na te cztery funkcje ma praktyczne znaczenie przy diagnozowaniu problemów. Jeśli widok pokazuje duplikat kolumny, przyczyny szuka się w CzyKolumnaIstnieje. Jeśli zapytanie z parametrem sesyjnym zwraca błędne dane, podejrzana jest PodstawZmienne. Taki podział ułatwia szybkie zawężenie miejsca awarii bez konieczności analizowania całej transakcji od początku.
Z perspektywy programisty czytającego kod po raz pierwszy taki podział na cztery wąsko zakresowe funkcje jest dużo łatwiejszy do zrozumienia niż jedna rozbudowana procedura robiąca wszystko naraz. Każda funkcja ma jedno zadanie i jedną odpowiedzialność, co ułatwia też pisanie testów oraz wprowadzanie zmian bez ryzyka zepsucia funkcjonalności niezwiązanej bezpośrednio ze zmianą.
Kolumny specjalne - Div i Button
Nie każda kolumna widoczna w zestawieniu pochodzi z zapytania SQL. Mechanizm UtworzStrukture usuwa kolumny, które przestały występować w wyniku zapytania, ale świadomie pomija przy tym kolumny specjalne typu Div i Button - dodawane ręcznie do interfejsu, na przykład jako przycisk akcji przy wierszu.
Gdyby ten wyjątek nie istniał, każda zmiana zapytania SQL widoku ryzykowałaby skasowanie ręcznie dodanych elementów interfejsu, zmuszając administratora do ich odtwarzania po każdej modyfikacji. Rozróżnienie kolumn danych od kolumn interfejsu pozwala bezpiecznie modyfikować zapytanie źródłowe bez obawy o utratę tych dodatków.
W praktyce kolumny specjalne odpowiadają najczęściej za akcje wykonywane na pojedynczym wierszu zestawienia - podgląd szczegółów, edycję, usunięcie albo uruchomienie powiązanej transakcji. Ich konfiguracja - jaka ikona, jaki kolor, jaka transakcja docelowa - ustawiana jest raz, ręcznie, i pozostaje niezmieniona niezależnie od tego, ile razy zmieni się później samo zapytanie SQL zasilające pozostałe kolumny widoku.
Podstawianie zmiennych sesyjnych
Funkcja PodstawZmienne wspiera dynamiczne zapytania SQL, zastępując zmienne takie jak @LOGIN czy @MAIL odpowiednimi wartościami z sesji zalogowanego użytkownika, a także bieżącą datą systemową. Dzięki temu jedno zapytanie zapisane raz w tabeli x_zestawienia może zwracać inny wynik dla każdego użytkownika - bez potrzeby tworzenia osobnego widoku dla każdej osoby czy roli.
Ten sam mechanizm podstawiania zmiennych sesyjnych, tylko w kontekście raportów RDL zamiast widoków tabelarycznych, opisano w materiale o Reporting Services w StudioSystem - w obu przypadkach zasada jest identyczna: ten sam zapisany raz zapytanie zachowuje się inaczej w zależności od tego, kto je uruchamia.
Konsekwencją takiego podejścia jest mniejsza liczba widoków do utrzymania. Zamiast osobnego zestawienia „moje zamówienia” dla każdego handlowca, wystarczy jeden widok z warunkiem filtrującym po zmiennej sesyjnej reprezentującej zalogowanego użytkownika. Administrator utrzymuje jedno zapytanie SQL zamiast dziesiątek niemal identycznych kopii, co ułatwia też wprowadzanie późniejszych poprawek - zmiana trafia od razu do wszystkich użytkowników korzystających z tego samego widoku.
Jak uruchomić raport
Baza_widok_tabela uruchamia się identycznie jak pozostałe raporty RDL platformy - transakcją raporty.aspx z parametrem raport wskazującym ścieżkę pliku na serwerze raportów, na przykład raport=/Firma_SoftwareStudio/Baza_widok_tabela. Domyślnie wynikiem jest podgląd na stronie, a parametr save pozwala zapisać wynik jako plik pdf lub xls do dalszej analizy poza systemem.
Praktyczne zastosowania
Raport przydaje się przede wszystkim w sytuacjach, gdy trzeba zrozumieć, dlaczego widok wygląda tak, a nie inaczej, bez przeglądania kodu transakcji adm_widok_kolumny.aspx ani samego zapytania SQL:
- Diagnostyka brakującej kolumny - szybkie sprawdzenie, czy kolumna w ogóle istnieje w x_zestawienia_kolumny, zanim zacznie się szukać błędu w zapytaniu SQL.
- Odróżnienie kolumn danych od interfejsu - eksport pokazuje, które kolumny są automatycznie generowane, a które to ręcznie dodane elementy specjalne.
- Audyt przed zmianą zapytania - porównanie obecnych kolumn z planowaną zmianą zapytania pozwala przewidzieć, które kolumny zostaną automatycznie usunięte.
- Dokumentacja dla zespołu wdrożeniowego - jeden eksport zamiast ręcznego katalogowania struktury każdego widoku z osobna.
Praktyczna wartość tego raportu w codziennej pracy rośnie wraz z wiekiem i skalą wdrożenia platformy. Świeżo skonfigurowany system ma niewiele widoków i łatwo je ogarnąć wzrokiem w module Konfiguracja. Po latach eksploatacji, gdy powstały już dziesiątki zestawień tworzonych na bieżące potrzeby różnych działów, ręczne przeglądanie struktury kolumn każdego z nich z osobna przestaje być realistyczne - i to właśnie wtedy jeden zbiorczy eksport zaczyna realnie oszczędzać czas pracy administratora, zamiast pozostawać wyłącznie teoretyczną możliwością opisaną w dokumentacji.
Podsumowanie
Baza_widok_tabela dokumentuje mechanizm, dzięki któremu kolumny widoków w StudioSystem nie są konfigurowane ręcznie, tylko generowane automatycznie przez transakcję adm_widok_kolumny.aspx na podstawie wyniku zapytania SQL zapisanego w tabeli x_zestawienia. Nowe kolumny są dodawane, nieaktualne usuwane, a kolumny specjalne typu Div i Button pozostają nietknięte.
Razem z raportem Baza_widok, opisującym listę samych widoków, oraz materiałem o konfiguracji widoków SQL, ten raport zamyka pełny obraz warstwy prezentacji danych platformy - od zapytania, przez kolumny, aż po gotowe zestawienie w interfejsie. Konwencje nazewnictwa tabel i widoków wykorzystane w tabelach x_zestawienia i x_zestawienia_kolumny opisano szerzej w dokumentacji struktury bazy danych.