Probieren Sie für noch mehr Spaß dieses aus:
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
:)
Die Antwort auf Ihre Frage lautet:"Historische Gründe"
Die Datentypen INT und VARCHAR sind älter als BIGINT und NVARCHAR. Viel älter. Tatsächlich sind sie im Original enthalten SQL-Spezifikationen. Ebenfalls älter ist der Ausnahme-unterdrückende Ansatz, die Ausgabe durch Sternchen zu ersetzen.
Später entschieden die SQL-Leute, dass das Auslösen eines Fehlers besser/konsistenter usw. sei, als falsche (und normalerweise verwirrende) Ausgabestrings zu ersetzen. Aus Konsistenzgründen wurde jedoch das vorherige Verhalten für die bereits vorhandenen Kombinationen von Datentypen beibehalten (um den vorhandenen Code nicht zu beschädigen).
Als also (viel) später die Datentypen BIGINT und NVARCHAR hinzugefügt wurden, bekamen sie das neue(ere) Verhalten, weil sie nicht von dem oben erwähnten Grandfathering abgedeckt waren.
