ROWVERSION (TIMESTAMP)

ROWVERSION to typ danych automatycznie generujący unikalną wartość binarną przy każdej zmianie wiersza.

ROWVERSION w Microsoft SQL Server — licznik zmian wierszy

ROWVERSION jest specjalnym typem danych Microsoft SQL Server, który przechowuje ośmiobajtową wartość binarną. Silnik automatycznie nadaje tę wartość podczas wstawiania lub modyfikowania wiersza zawierającego kolumnę typu rowversion. Wartość pochodzi z licznika prowadzonego na poziomie bazy danych, a nie z zegara systemowego. Z tego powodu nie opisuje daty ani godziny operacji i nie należy jej interpretować jako znacznika czasu w sensie kalendarzowym.

Wartości generowane w jednej bazie danych są użyteczne do wykrywania, że między dwoma odczytami zaszła zmiana. Mogą występować przerwy w numeracji, dlatego aplikacja nie powinna zakładać, że każda kolejna wartość różni się dokładnie o jeden. Licznik jest związany z konkretną bazą danych, więc wartość rowversion nie stanowi globalnego identyfikatora rekordu ani informacji pozwalającej bezpośrednio porównywać zmiany pomiędzy różnymi bazami.

Dlaczego TIMESTAMP nie oznacza daty i czasu

W SQL Server słowo kluczowe TIMESTAMP jest historycznym synonimem typu ROWVERSION. Nie jest to odpowiednik kolumny przechowującej datę i godzinę, takiej jak datetime2. Nowy kod powinien używać nazwy rowversion, ponieważ lepiej odzwierciedla rzeczywiste działanie mechanizmu i nie prowadzi do pomylenia go z czasem wykonania operacji.

Przykładowa definicja tabeli może zawierać kolumnę rv rowversion NOT NULL. Przy dodaniu rekordu SQL Server sam wygeneruje jej wartość, a przy zmianie rekordu nada nową wartość. Aplikacja nie powinna próbować ustawiać tej kolumny zwykłym poleceniem INSERT lub UPDATE. Do przechowywania momentu utworzenia albo modyfikacji należy zastosować osobną kolumnę typu daty i czasu, na przykład datetime2, wraz z odpowiednią logiką uzupełniania tej kolumny.

Wartość można odczytać i przesłać do aplikacji jako dane binarne. W zapytaniach porównuje się ją z wartością wcześniej pobraną z tego samego wiersza. Nie powinno się natomiast wyświetlać jej użytkownikowi jako daty, wykonywać na niej operacji arytmetycznych właściwych dla czasu ani traktować jej jako informacji o tym, kiedy dokładnie zmieniono dane.

Kontrola równoczesnej aktualizacji rekordu

Najczęstszym zastosowaniem rowversion jest kontrola optymistycznej współbieżności. Aplikacja najpierw odczytuje rekord wraz z jego bieżącą wartością rowversion. Następnie użytkownik edytuje dane, a aplikacja wysyła aktualizację zawierającą także pierwotnie odczytaną wartość. Warunek aktualizacji powinien sprawdzać, czy wartość w bazie nadal jest taka sama, przykładowo poprzez logiczne połączenie identyfikatora rekordu z warunkiem rv = @original_rv.

Jeżeli inny proces zmienił wcześniej ten sam wiersz, SQL Server nadał mu nową wartość rowversion. Wtedy warunek z pierwotną wartością nie pasuje do żadnego rekordu i polecenie aktualizuje zero wierszy. Aplikacja powinna wykryć ten wynik i potraktować go jako konflikt, zamiast bezwarunkowo nadpisywać dane. Możliwą reakcją jest ponowne odczytanie rekordu, pokazanie użytkownikowi aktualnej wersji i poproszenie o świadome połączenie zmian.

Mechanizm nie zastępuje transakcji, blokad ani poprawnego modelu uprawnień. Chroni przed określonym rodzajem utraty zmian w scenariuszu odczyt–edycja–zapis, ale sam nie rozwiązuje problemów wynikających z kilku powiązanych tabel, błędnej kolejności operacji lub niewłaściwego poziomu izolacji transakcji. Wartość zwrócona po aktualizacji powinna zostać ponownie odczytana albo pobrana zgodnie z użytym sposobem wykonywania zapytania, jeśli aplikacja potrzebuje znać nową wersję rekordu.

Praktyczne użycie przy analizie danych SQL Server

Podczas diagnostyki aplikacji korzystającej z SQL Server należy sprawdzić, czy kolumna jest rzeczywiście typu rowversion, czy kod nie traktuje jej jak daty oraz czy aktualizacje kontrolują liczbę zmodyfikowanych wierszy. Istotne jest także ustalenie, z której bazy pochodzi porównywana wartość. Ta sama reprezentacja binarna nie daje podstaw do wnioskowania o kolejności zmian pomiędzy niezależnymi bazami, kopiami danych lub środowiskami testowym i produkcyjnym.

W zapytaniach raportowych kolumnę można zwracać razem z pozostałymi polami, ale jej znaczenie powinno być opisane jako wersja zmiany rekordu. Warto pamiętać, że sama obecność nowej wartości nie dostarcza informacji o tym, które pole zostało zmienione. Do ustalenia zakresu modyfikacji potrzebne są dane historyczne, dziennik zmian albo mechanizm audytowy skonfigurowany niezależnie od rowversion. Wartość może służyć do wykrycia różnicy między odczytem a zapisem, lecz nie jest historią zmian.

W przypadku problemów z zapisem na komputerze używanym do pracy z aplikacją technik może zweryfikować komunikaty SQL Server, parametry zapytania, typ przekazywanej wartości binarnej oraz wynik instrukcji aktualizującej. Szczególnej uwagi wymaga sytuacja, w której aplikacja zgłasza konflikt mimo braku widocznej edycji użytkownika: przyczyną może być aktualizacja wykonywana przez inne zadanie, procedurę lub proces synchronizacji. Taką przyczynę należy potwierdzić analizą konkretnych zapytań i kolejności operacji, a nie zamianą rowversion na kolumnę daty.