Utrata precyzji liczbowej serwera SQL 2005

Podobnie jak dodanie typu zmiennoprzecinkowego jest niedokładne, mnożenie typów dziesiętnych może być niedokładne (lub powodować niedokładność), jeśli przekroczysz precyzję. Zobacz Konwersja typu danych i dziesiętne i numeryczne .

Ponieważ pomnożyłeś NUMERIC(24,8) i NUMERIC(24,8) , a SQL Server sprawdzi tylko typ, a nie zawartość, prawdopodobnie spróbuje zapisać potencjalne 16 cyfr niedziesiętnych (24 - 8), gdy nie może zapisać wszystkich 48 cyfr precyzji (maksymalnie 38). Łącząc dwa z nich, otrzymasz 32 cyfry niedziesiętne, co daje tylko 6 cyfr dziesiętnych (38 - 32).

Tak więc pierwotne zapytanie

SELECT A, B, C, A + B * C
FROM ( SELECT CAST(0.12345678 AS NUMERIC(24,8)) AS A,
  CAST(0 AS NUMERIC(24,8)) AS B,
  CAST(500 AS NUMERIC(24,8)) AS C ) T

zmniejsza się do

SELECT A, B, C, A + D
FROM ( SELECT CAST(0.12345678 AS NUMERIC(24,8)) AS A,
  CAST(0 AS NUMERIC(24,8)) AS B,
  CAST(500 AS NUMERIC(24,8)) AS C,
  CAST(0 AS NUMERIC(38,6)) AS D ) T

Ponownie, między NUMERIC(24,8) i NUMERIC(38,6) , SQL Server spróbuje zapisać potencjalne 32 cyfry liczby niedziesiętnej, więc A + D zmniejsza się do

SELECT CAST(0.12345678 AS NUMERIC(38,6))

co daje 0.123457 po zaokrągleniu.