COLLATE DATABASE_DEFAULT to opcja przywracająca domyślne ustawienia sortowania znaków zdefiniowane na poziomie bazy danych.
Rola klauzuli COLLATE DATABASE_DEFAULT w SQL Server
COLLATE DATABASE_DEFAULT jest składnią języka Transact-SQL używaną w Microsoft SQL Server do wskazania, że dana operacja tekstowa ma korzystać z domyślnego sortowania znaków ustalonego dla bieżącej bazy danych. Klauzula COLLATE określa reguły porównywania i porządkowania tekstu, a także sposób interpretowania wielkości liter, akcentów oraz niektórych znaków języków narodowych. Wartość DATABASE_DEFAULT nie jest nazwą konkretnej kolacji, lecz poleceniem odwołującym się do ustawienia domyślnego bazy.
Przykładowo wyrażenie tekst COLLATE DATABASE_DEFAULT wymusza użycie kolacji bazy dla tego wyrażenia. Składnia może być stosowana przy kolumnach i wyrażeniach znakowych, między innymi typu char, varchar, nchar oraz nvarchar. Nie dotyczy bezpośrednio wartości liczbowych, dat ani innych typów, które nie przechowują tekstu. Efekt obejmuje konkretne porównanie, sortowanie albo operację tekstową, w której klauzula została użyta.
Kolacja bazy a porównywanie tekstu
Kolacja w SQL Server opisuje więcej niż kolejność znaków w wynikach zapytania. Zawiera między innymi reguły rozróżniania wielkości liter oraz akcentów. Kolacja oznaczona jako niewrażliwa na wielkość liter może traktować litery „A” i „a” jako równoważne podczas porównania, natomiast kolacja wrażliwa na wielkość liter rozróżnia te wartości. Podobne zasady dotyczą znaków diakrytycznych, na przykład „a” i „ą”. Konkretne zachowanie wynika z kolacji przypisanej do bazy, tabeli, kolumny lub wyrażenia.
Użycie DATABASE_DEFAULT może ujednolicić zachowanie zapytania z regułami obowiązującymi w danej bazie. Ma to znaczenie przy operatorach =, LIKE, ORDER BY, grupowaniu oraz łączeniu danych tekstowych. Jeżeli dwa elementy tekstowe mają różne kolacje, SQL Server może zgłosić konflikt kolacji i przerwać wykonanie zapytania. Jawne wskazanie COLLATE DATABASE_DEFAULT na odpowiednim wyrażeniu może rozstrzygnąć, które reguły mają zostać zastosowane, ale nie zmienia trwale definicji kolumn ani ustawień całej bazy.
Tempdb, tabele tymczasowe i konflikt ustawień
Typowym zastosowaniem tej klauzuli są tabele tymczasowe. Tabele tymczasowe są tworzone w systemowej bazie tempdb, która może mieć inną kolację niż baza użytkownika. W takiej sytuacji kolumna tekstowa tabeli tymczasowej może otrzymać kolację wynikającą z ustawień tempdb, a kolumna stałej tabeli może korzystać z kolacji bazy aplikacyjnej. Porównanie tych kolumn, na przykład w klauzuli JOIN, może wtedy zakończyć się komunikatem o konflikcie kolacji.
Przy definiowaniu kolumny tekstowej tabeli tymczasowej można użyć składni w rodzaju nvarchar(100) COLLATE DATABASE_DEFAULT. W tym kontekście SQL Server przypisuje kolumnie kolację domyślną bieżącej bazy użytkownika, a nie domyślną kolację tempdb. Rozwiązanie jest przydatne w procedurach składowanych, raportach i zapytaniach roboczych wykorzystujących dane tymczasowe. Należy jednak świadomie ustalić kontekst bazy, ponieważ określenie „domyślna baza danych” odnosi się do bazy, w której wykonywana jest instrukcja, a nie do dowolnej bazy obecnej na tym samym serwerze.
Zakres działania i konsekwencje diagnostyczne
COLLATE DATABASE_DEFAULT działa lokalnie tam, gdzie zostało użyte. Nie naprawia automatycznie niespójności wszystkich kolumn, nie konwertuje danych zapisanych w tabelach i nie zmienia domyślnej kolacji serwera. Zmiana domyślnej kolacji bazy za pomocą ustawień administracyjnych również nie oznacza automatycznej zmiany kolacji istniejących kolumn. Dlatego przed zastosowaniem klauzuli trzeba ustalić, czy problem dotyczy pojedynczego porównania, tabeli tymczasowej, definicji kolumny, czy szerszej konfiguracji bazy.
W diagnostyce należy sprawdzić kolację bazy, kolację poszczególnych kolumn oraz miejsce utworzenia tabel tymczasowych. Pomocne może być odczytanie metadanych kolumn i jawne przeanalizowanie zapytania, które zgłasza konflikt. Doraźne wymuszenie kolacji na wyrażeniu może usunąć błąd wykonania, ale przy dużych zbiorach danych może wpływać na plan zapytania i możliwość wykorzystania indeksu. Właściwe rozwiązanie powinno uwzględniać wymagane reguły sortowania, typ danych, kierunek konwersji oraz oczekiwane zachowanie porównań w całej aplikacji.
