sql >> Database >  >> RDS >> Sqlserver

Waarom casten/converteren van int een asterisk retourneert

Probeer deze voor nog meer plezier:

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

:)

Het antwoord op uw vraag is:"Historische redenen"

De datatypes INT en VARCHAR zijn ouder dan BIGINT en NVARCHAR. Veel ouder. In feite zijn ze in de originele SQL-specificaties. Ook ouder is de uitzonderingsonderdrukkende benadering van het vervangen van de uitvoer door sterretjes.

Later besloten de SQL-mensen dat het geven van een fout beter/consistenter was, enz. dan het vervangen van valse (en meestal verwarrende) uitvoerstrings. Omwille van de consistentie behielden ze echter het eerdere gedrag voor de reeds bestaande combinaties van gegevenstypen (om de bestaande code niet te breken).

Dus (veel) later, toen de datatypes BIGINT en NVARCHAR werden toegevoegd, kregen ze het nieuwe(re) gedrag omdat ze niet onder de bovengenoemde grootvaderregeling vielen.



  1. Fatale fout:oproep naar ongedefinieerde functie mysqli_result()

  2. NULL vs. 'oneindig' in PostgreSQL-bereiktypen

  3. SQL Server-afstemming - het draait allemaal om meten

  4. 4 manieren om te controleren op dubbele rijen in SQL Server