SET DATEFIRST

SET DATEFIRST określa, który dzień tygodnia jest traktowany jako pierwszy w bieżącej sesji.

SET DATEFIRST – czym jest i do czego służy

SET DATEFIRST to polecenie języka T-SQL używanego w Microsoft SQL Server. Pozwala ustalić, który dzień tygodnia ma być uznawany za pierwszy w bieżącej sesji połączenia z bazą danych. Ustawienie to wpływa przede wszystkim na wynik funkcji DATEPART dla elementu weekday oraz na sposób interpretowania numeru dnia zwracanego przez tę funkcję. Nie zmienia ono dat zapisanych w tabelach, nie przesuwa kalendarza i nie modyfikuje wartości typu date, datetime ani datetime2. Zmienia jedynie regułę stosowaną podczas obliczeń wykonywanych w konkretnej sesji.

Składnia polecenia ma postać SET DATEFIRST n, gdzie n jest liczbą od 1 do 7. Poszczególne wartości oznaczają kolejne dni tygodnia, przy czym ich znaczenie zależy od ustawień językowych serwera. W typowym ustawieniu angielskim wartość 1 oznacza niedzielę, a wartość 7 sobotę. Przy polskim kontekście pracy często oczekuje się, że poniedziałek będzie dniem numer 1, dlatego przed napisaniem raportu lub procedury należy sprawdzić, jakie ustawienie ma zostać przyjęte. Samo polecenie nie powinno być traktowane jako uniwersalna zmiana konfiguracji całej bazy danych.

Zakres działania jest sesyjny. Po wykonaniu polecenia w jednym połączeniu zmiana obowiązuje dla dalszych instrukcji uruchamianych w tym połączeniu, ale nie musi obowiązywać w innym oknie zapytania, połączeniu aplikacyjnym ani zadaniu wykonywanym przez osobny proces. W praktyce oznacza to konieczność świadomego ustawiania kolejności operacji. Jeżeli kod zależy od numeru dnia tygodnia, polecenie powinno zostać umieszczone w tym samym skrypcie lub procedurze, w której wykonywane są obliczenia.

SET DATEFIRST a DATEPART, DATENAME i kalendarz

Najbardziej widoczny efekt SET DATEFIRST pojawia się przy użyciu wyrażenia DATEPART(weekday, data) albo jego skróconego wariantu DATEPART(dw, data). Zwrócona liczba nie jest stałą, niezależną właściwością daty. Jest numerem pozycji dnia tygodnia w kolejności wyznaczonej przez aktualne ustawienie sesji. Ta sama data może więc otrzymać inną liczbę po zmianie DATEFIRST, mimo że data sama w sobie pozostaje identyczna.

Przykładowo, jeśli raport ma oznaczać dni robocze jako wartości od 1 do 5, trzeba najpierw ustalić, czy numer 1 oznacza poniedziałek. Bez tego warunek oparty na zakresie liczb może uznać sobotę lub niedzielę za dzień roboczy. Bezpieczniejszy zapis wymaga jawnego zdefiniowania oczekiwanej kolejności albo zastosowania dodatkowej logiki, która nie opiera się wyłącznie na domyślnej konfiguracji. W systemach przekazywanych między różnymi środowiskami ma to szczególne znaczenie, ponieważ ustawienia języka i pierwszego dnia tygodnia mogą być inne na serwerze testowym, produkcyjnym i na stanowisku osoby analizującej dane.

Funkcja DATENAME(weekday, data) zwraca nazwę dnia tygodnia, na przykład nazwę odpowiadającą poniedziałkowi lub piątkowi. Sama nazwa zależy od języka sesji, natomiast jej kolejność w tygodniu nie powinna być ustalana przez porównywanie tekstów. Z tego powodu kod przeznaczony do raportowania powinien rozdzielać dwie kwestie: kolejność dni potrzebną do sortowania oraz język prezentowanej etykiety. SET DATEFIRST wpływa na numerowanie dni, ale nie jest narzędziem do tłumaczenia nazw dni tygodnia.

Warto również odróżnić DATEPART dla elementu weekday od obliczania numeru tygodnia. Polecenie SET DATEFIRST może wpływać na wynik części operacji związanych z tygodniem, ale nie rozwiązuje wszystkich problemów z numeracją tygodni na przełomie roku. Jeżeli wymagany jest standard ISO, należy dobrać właściwą funkcję i regułę biznesową, a nie zakładać, że samo ustawienie pierwszego dnia tygodnia zapewni zgodność z ISO 8601.

SET DATEFIRST – typowe problemy w zapytaniach

Jednym z częstych błędów jest użycie warunku DATEPART(weekday, data) IN (1, 7) z założeniem, że zawsze oznacza on weekend. Taki zapis jest poprawny tylko wtedy, gdy kolejność dni i numeracja zostały wcześniej jednoznacznie ustalone. Po zmianie SET DATEFIRST wartości graniczne mogą wskazywać inne dni. W efekcie raport może błędnie liczyć czas pracy, obciążenie, terminy realizacji albo liczbę zdarzeń przypadających na weekend.

Innym problemem bywa sortowanie nazw dni tygodnia według alfabetu. Kolejność piątek, poniedziałek, sobota, środa i wtorek nie odpowiada kolejności kalendarzowej, nawet jeśli same nazwy są prawidłowe. Zaleca się przechowywanie osobnego numeru kolejności wyliczonego zgodnie z przyjętą regułą oraz używanie go w klauzuli ORDER BY. Nazwa dnia powinna pełnić funkcję opisową, a nie sterować sortowaniem.

Ryzyko pojawia się również przy łączeniu danych z kilku źródeł. Aplikacja może otworzyć połączenie, wykonać część zapytań, a następnie zwrócić je do puli połączeń. Kolejny użytkownik może otrzymać to samo połączenie z wcześniejszym ustawieniem sesji. Jeżeli kod nie ustawia jawnie DATEFIRST, wynik może zależeć od historii użycia danego połączenia. Z tego względu ustawienia sesyjne powinny być traktowane jako element środowiska wykonania i kontrolowane w kodzie aplikacji lub procedury.

Do diagnostyki przydatne jest sprawdzenie bieżących ustawień sesji za pomocą odpowiednich funkcji i poleceń systemowych, a także wykonanie krótkiego testu dla znanej daty. Taki test powinien obejmować kilka wartości DATEFIRST oraz sprawdzać wynik DATEPART. Pozwala to ustalić, czy problem wynika z samego zapytania, z języka sesji, z ustawień połączenia, czy z błędnego założenia przyjętego w raporcie.

SET DATEFIRST – praktyczne wskazówki dla kodu

Przed użyciem SET DATEFIRST należy opisać regułę biznesową zwykłymi słowami. Wymaganie „tydzień zaczyna się w poniedziałek” jest jednoznaczniejsze niż wymaganie „dzień roboczy ma numer od 1 do 5”. Następnie trzeba dopasować do tej reguły obliczenia, sortowanie i prezentację. Warto także ustalić, czy tydzień ma znaczenie tylko dla widoku użytkownika, czy również dla agregacji i filtrowania danych.

W procedurach składowanych wskazane jest umieszczanie ustawienia na początku fragmentu, który korzysta z numerów dni tygodnia. Dzięki temu osoba czytająca kod widzi zależność bez szukania konfiguracji w innym miejscu. W zapytaniach raportowych można stosować jawne aliasy, komentarze i testowe przykłady dat. Takie działania ograniczają ryzyko, że po zmianie konfiguracji serwera raport zacznie zwracać inne wyniki bez widocznego błędu technicznego.

Nie należy przechowywać w tabeli wyłącznie numeru dnia tygodnia wyliczonego przy jednym ustawieniu, jeżeli później dane mają być używane w innych kontekstach. Lepszym źródłem pozostaje pełna data, a numer dnia powinien być wyliczany zgodnie z aktualnie przyjętą regułą albo zapisany razem z informacją o standardzie, według którego został utworzony. Szczególnej uwagi wymagają widoki, funkcje użytkownika, procedury oraz kod generowany przez narzędzia raportowe, ponieważ zależność od ustawień sesji może być w nich ukryta.

Przy testowaniu należy sprawdzić daty przypadające na każdy dzień tygodnia, początek i koniec miesiąca, przełom roku oraz dni znajdujące się w pobliżu zmian czasu lub granic okresów raportowych, jeśli system je uwzględnia. Warto porównać wynik dla kilku połączeń, ponieważ ustawienia jednego okna zapytania nie muszą odzwierciedlać zachowania aplikacji działającej wielowątkowo.

SET DATEFIRST – kiedy zgłosić się do serwisu

Wsparcie serwisowe może być potrzebne wtedy, gdy raporty pokazują niewłaściwy dzień tygodnia, zestawienia weekendowe różnią się między użytkownikami albo procedura zwraca inne wyniki po ponownym uruchomieniu aplikacji. W takich przypadkach analizuje się treść zapytań, ustawienia sesji, sposób zarządzania połączeniami oraz zgodność danych z regułą kalendarzową przyjętą w organizacji. Sama obecność polecenia SET DATEFIRST nie przesądza jeszcze o poprawności rozwiązania, ponieważ znaczenie mają również funkcje użyte w dalszej części kodu.

Przed przekazaniem problemu warto przygotować przykładową datę, oczekiwany wynik, wynik rzeczywisty, tekst zapytania oraz informację, czy błąd występuje w każdym połączeniu. Pomocne jest również wskazanie, czy problem dotyczy tylko numeru dnia, czy także nazwy dnia, numeru tygodnia i sortowania. Tak zebrane dane ułatwiają odtworzenie sytuacji i ograniczają ryzyko poprawienia jednego raportu przy pozostawieniu tej samej niejednoznaczności w innych miejscach.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić analizę problemu z działaniem komputera lub oprogramowania, gdy nieprawidłowe wyniki zapytań są częścią szerszych trudności ze środowiskiem pracy. W pierwszej kolejności ustala się, czy przyczyna leży w kodzie SQL, konfiguracji połączenia, ustawieniach językowych, aplikacji raportowej czy w samym komputerze. Dopiero na tej podstawie dobiera się dalsze działania, tak aby zachować spójność wyników i możliwość ich późniejszego zweryfikowania.