advertencia SQL Server 2000

[scooterjgm]

Estimados, el problema que se planteo a continuación está relacionado con Delphi 7, SQL Server 2000 y componentes nativos de ADO.

Tengo un procedimiento almacenado que ejecuto a través de un TADOQuery, el cual me devuelve mensajes de advertencia del tipo:

Código SQL [-]
 
Advertencia: se creó la tabla '#table', pero su tamaño máximo de fila (8289) supera el número máximo de bytes 
por fila (8060). El uso de INSERT o UPDATE en una fila de esta tabla producirá un error si la longitud de la fila 
resultante supera 8060 bytes.

El analizador de SQL me devuelve correctamente los datos, pero en cambio, el TADOQuery me muestra la advertencia en pantalla ya que la toma como un error.

¿Cómo puedo hacer para discriminar estos mensajes de advertencia?

Un Saludo y muchas gracias por leer este hilo.

[Neftali [Germán.Estévez]]

Utiliza un Try..except cuando lanzas el ADOQuery (Exec/Open) y captura las excepciones de tipo EOLEException.
A partir de ahí consulta el E.ErrorCode para determinar qué ErrorCode trae esta y discrimina las de ese error.

[scooterjgm]

Muchas gracias por ayudarme!! Siempre se aprenden cosas nuevas y hoy ya he cumplido

La discriminación del error no me ha solucionado el problema del todo.

  try
    Query.Open;
  except
    on E:EOLEException do
    begin
      ShowMessage ('Warning EOLEException!!');
    end;
end;

Con esto capturo el error pero los datos no llegan a la TADOQuery. Apunto algo más, la Query la utilizo para generar un informe espécifico y necesito los datos.

La idea es 'pasar del warning' (el analizador lo muestra como una advertencia y muestra los datos).

[scooterjgm]

Comparto con todos la información que he encontrado acerca de este problema.

En http://www.sommarskog.se/error-handling-I.html#ADO dice lo siguiente:

ADO also takes the freedom to make its own considerations about what is an error. I found that ADO always considers division by zero to be an error, even if both ARITHABORT and ANSI_WARNINGS are OFF. In this case, SQL Server merely produces a warning, but ADO opts to handle this warning as an error. A good thing in my opinion. Of what I have found, this only happens with division by zero; not with arithmetic errors such as overflow.

De momento tengo el porqué del problema pero no la solución.

[scooterjgm]

Debido a que el único caso ocurre con el warning division by zero, como solución provisional he incorporado una comprobación en el procedimiento almacenado antes de obtener el resultado de la operación.

Código SQL [-]
 
IF @formula LIKE '%/0%' SET @salida=0

Con esto, si la fórmula contiene alguna división entre cero, evito que se ejecute el procedimiento que me calcula el resultado de la fórmula.

como he dicho antes, esto es una medida provisional ya que no estaría contemplado el caso de una división entre un paréntesis cuyo resultado sea cero.

Ej: 250/(10-10)

Debería ir obteniendo resultados parciales y realizando la misma comprobación pero ando pillado de tiempo y lo dejo para otro rato.

Muchas gracias a todos los que habeis dedicado tiempo a leer este hilo y en especial a Neftali por su respuesta.

Un saludo a tod@s.

[scooterjgm]

Bueno, pues 9 meses después creo tener la solución a mí problema. Voy a detallar paso por paso los problemas que he tenido...

1- La siguiente consulta me da error de división por cero:

SELECT 1/0 as CERO,1 as UNO

2- La siguiente solución sirve para el resto de warnings pero no para el de 'división por cero' ya que ADO lo sigue tomando como error según el artículo del post anterior:

SET ANSI_WARNINGS OFF
SET ARITHABORT OFF
 
SELECT 1/0 as CERO,1 as UNO

3- Añadiendo una linea más, se puede conseguir que SQL Server no muestre ningún warning:

SET ANSI_WARNINGS OFF
 
SET ARITHIGNORE ON
 
SET ARITHABORT OFF
SELECT 1/0 as CERO,1 as UNO

Problema resuelto... muchas gracias a todos los que os habeis interesado en el tema. Espero que esto pueda salvar la vida a más programadores

[mamcx]

Pero el error original que tiene que ver con la division por 0? ME PERDI!

Esos es un desbordamiento, tipico de poner un unicode char/varchar y meterle un ANSI char.

[scooterjgm]

Empezado por mamcx

Pero el error original que tiene que ver con la division por 0? ME PERDI!

Esos es un desbordamiento, tipico de poner un unicode char/varchar y meterle un ANSI char.

Al ejecutar la consulta original, me aparecían varias advertencias, y el de error texto que tomaba al encontrarse con la divisón por cero era la primera advertencia que aparecía. Ese mensaje me llevó a la confusión...