Desbordamiento aritmético en la consulta SELECT

9

Encontré un desbordamiento aritmético en una simple instrucción SELECT. La consulta fue como a continuación, por ejemplo

SELECT [SaleValue] FROM Sales

[SaleValue]era de tipo de datos decimal(9,0)y no una columna calculada.

La razón por la que esto sucedió fue porque de alguna manera la columna tenía una fila donde este campo almacenaba un valor MAYOR que el tipo de datos especificado, por ejemplo decimal(10,0).

Solo podía hacer que la selección funcionara cuando aumentaba el tamaño de la columna. La tabla en cuestión tiene otras dos instancias en otras dos columnas y filas.

¿Cómo fue posible esta situación? ¿Cómo se guardó un valor fuera de rango en la columna en primer lugar?

Estoy usando el servidor Microsoft SQL + esta es una tabla base, no una vista.


fuente
1
La única forma posible de pensar que tal vez obligue a que esto suceda sería editar las tablas del sistema a través del DAC, un proceso bastante violento que alguien podría decirle si se hubiera hecho a este DB. Incluso entonces, no estoy seguro de que funcione bien (o incluso sea posible). Fuera de eso, realmente necesitamos un script de repro para ver esta situación por nosotros mismos y sospecho que crear el repro, si es posible, podría llevar años de experimentación.
Damien_The_Unbeliever
Peor aún, acabo de recordar que 9/10 es un punto de corte para el tamaño de almacenamiento de decimal- a decimal(9,0)debería ocupar 5 bytes, un decimal(10,0)9. Por lo tanto, creo que es menos probable que pueda hacer esto editando las tablas del sistema ya que no tendrá El tamaño de almacenamiento correcto para los datos en cada fila.
Damien_The_Unbeliever
1
@Damien_The_Unbeliever No tengo idea de cómo reproducir. Me llevó una hora descubrir qué pasó. Verlo era como ver agua seca o calor frío. Honestamente, me dejó perplejo.

Respuestas:

15

Esto puede suceder de varias maneras, por ejemplo, como se describe en Solución de problemas del error DBCC 2570 en SQL Server 2005 y versiones posteriores :

Los datos no válidos o fuera de rango pueden haberse almacenado en la base de datos de SQL Server en versiones anteriores por los siguientes motivos:

  • Los datos no válidos estaban presentes en la fuente al usar métodos de inserción masiva, como la utilidad bcp.
  • Los datos no válidos se pasaron a través de llamadas de eventos RPC realizadas a SQL Server.
  • Otras causas potenciales de corrupción de datos físicos dejaron el valor de la columna en un estado no válido.

Ese artículo contiene mucha información útil sobre el tema. Para lo básico, consulte la documentación DBCC CHECKDBy la DATA_PURITYopción en particular.

Paul White 9
fuente