За още по-забавно, опитайте това:
DECLARE @i INT
SET @i = 100
SELECT CAST(@i AS VARCHAR(2)) -- result: '*'
go
DECLARE @i INT
SET @i = 100
SELECT CAST(@i AS NVARCHAR(2)) -- result: Arithmetic overflow error
:)
Отговорът на вашето запитване е:„Исторически причини“
Типовете данни INT и VARCHAR са по-стари от BIGINT и NVARCHAR. Много по-стари. Всъщност те са в оригинала SQL спецификации. Също така по-стар е подходът за потискане на изключенията за замяна на изхода със звездички.
По-късно SQL хората решиха, че хвърлянето на грешка е по-добро/по-последователно и т.н., отколкото заместването на фалшиви (и обикновено объркващи) изходни низове. За последователност обаче те запазиха предишното поведение за вече съществуващите комбинации от типове данни (за да не нарушат съществуващия код).
Толкова (много) по-късно, когато бяха добавени типове данни BIGINT и NVARCHAR, те получиха новото(по) поведение, защото не бяха обхванати от споменатото по-горе дядо.
