Pregunta Por qué lanzar / convertir desde int devuelve un asterisco


Alguien me hizo esta pregunta recientemente y pensé que la publicaría en Stack Overflow para obtener algo de información.

Ahora, obviamente, se supone que ambos escenarios siguientes fallan.

# 1:

DECLARE @x BIGINT
SET @x = 100
SELECT CAST(@x AS VARCHAR(2))

Error obvio:

Msg 8115, nivel 16, estado 2, línea 3
  Error de desbordamiento aritmético que convierte la expresión al tipo de datos varchar.

# 2:

DECLARE @x INT
SET @x = 100
SELECT CAST(@x AS VARCHAR(2))

No es obvio, devuelve un * (¿Uno esperaría que esto fuera un desbordamiento aritmético también?)


Ahora mi verdadera pregunta es, ¿por qué? ¿Es esto simplemente por diseño o hay historia o algo siniestro detrás de esto?

Miré algunos sitios y no pude obtener una respuesta satisfactoria.

p.ej. http://beyondrelational.com/quiz/sqlserver/tsql/2011/questions/Why-does-CAST-function-return-an-asterik--star.aspx

http://msdn.microsoft.com/en-us/library/aa226054(v=sql.80).aspx

Tenga en cuenta que sé que cuando un entero es demasiado grande para convertirlo en una cadena de tamaño específico que se "convertirá" en un asterisco, esta es la respuesta obvia y me gustaría poder rechazar a todos los que continúan dando esta respuesta . Quiero saber por qué se usa un asterisco y no una excepción, por ejemplo, razones históricas, etc?


32
2018-02-03 05:20


origen


Respuestas:


Para aún más diversión, prueba este:

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

:)


La respuesta a su consulta es: "Razones históricas"

Los tipos de datos INT y VARCHAR son más antiguos que BIGINT y NVARCHAR. Mucho mayor. De hecho, están en el original Especificaciones de SQL. También es más antiguo el enfoque de supresión de excepciones de reemplazar la salida con asteriscos.

Más adelante, la gente de SQL decidió que lanzar un error era mejor / más consistente, etc. que sustituir cadenas de salida falsas (y generalmente confusas). Sin embargo, por coherencia mantuvieron el comportamiento anterior para las combinaciones preexistentes de tipos de datos (para no romper el código existente).

Así que (mucho) más tarde cuando se agregaron los tipos de datos BIGINT y NVARCHAR, obtuvieron el nuevo (o) comportamiento porque no estaban cubiertos por el "grandfather" mencionado anteriormente.


30
2018-04-08 05:57



Puedes leer en el CAST y CONVERTIR página en la sección "Truncar y redondear resultados". Int, smallint y tinyint devolverán * cuando la longitud del resultado sea demasiado corta para mostrar cuando se convierta en char o varchar. Otras conversiones de cadena a numérica devolverán un error.


2
2018-02-21 05:23