Aby uzyskać jeszcze więcej zabawy, wypróbuj ten:
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
:)
Odpowiedź na Twoje pytanie brzmi:„Przyczyny historyczne”
Typy danych INT i VARCHAR są starsze niż BIGINT i NVARCHAR. Dużo starszy. W rzeczywistości są w oryginalnym Specyfikacje SQL. Starsze jest również podejście polegające na eliminowaniu wyjątków polegające na zastępowaniu danych wyjściowych gwiazdkami.
Później ludzie zajmujący się SQL zdecydowali, że zgłoszenie błędu było lepsze/bardziej spójne itp. niż zastępowanie fałszywych (i zwykle mylących) ciągów wyjściowych. Jednak ze względu na spójność zachowali poprzednie zachowanie dla wcześniej istniejących kombinacji typów danych (aby nie złamać istniejącego kodu).
Tak więc (dużo) później, gdy dodano typy danych BIGINT i NVARCHAR, otrzymały nowe (er) zachowanie, ponieważ nie były objęte wspomnianym wyżej dziadkiem.
