Omitir notificación de errores (II)

31/08/2004 - 16:24 por Max Castro V. | Informe spam
Desde ya muchas gracias a quienes aportaron sugerencias a
mi consulta de ayer. Al respecto los siguientes
comentarios.

Mi idea central es crear una interfaz de sp que
permitan a una aplicación cliente interactuar con una BD.
Para ello definí que cada entidad (Tabla) de la BD tuviese
dos sp asociados: uno para visualizar (SELECT) y otro para
gestionar modificaciones (INSERT, UPDATE, DELETE). Mi idea
es que cualquier resultado de estos sp, sea un conjunto de
datos o un mensaje (error o correcto) sea devuelto a
través de un recordset. Para esto necesito que el sp se
ejecute siempre correctamente.

Adrian García propone verificar las reglas en forma
manual (IF EXISTS ...) antes de realizar el INSERT. Javier
Loria propone un interesante método en función de la
utilización de una subconsulta que verifica la existencia
de los Id en la tabla foránea. Mi problema es que pretendo
generalizar este método a tablas más grandes que el caso
del ejemplo (Mayor cantidad de campos, varios Ids foráneos
y miles de registros) por lo que la ejecución del sp sería
muy costosa en términos de recursos (En el primer caso por
la cantidad de tablas anexas que habría que comprobar y en
el segundo por la cantidad de recursos necesarios al
cruzar en forma simultánea las tablas necesarias).
Asimismo mi intención es hacer algo parecido para las
intrucciones DELETE, es decir no generar errores al
momento de intentar eliminar un registro que en otra tabla
aparezca como clave foránea.

Dado lo anterior, es que lo más simple era intentar el
tratar de manejar el error como en VB que puedo detectarlo
y manipularlo a través de una rutina controladora de
errores, para luego -si deseo- proseguir con la ejecución
normal.

Javier comenta que una vez producido el error no hay forma
de restaurar al estado de 'no error' y dado que en la
ayuda de SQL no hay nada que me haga pensar lo contrario,
me estoy replanteando la salida que había pensado para mis
sp, al respecto dejo abierta el tema:

¿Es buena idea devolver mensajes y datos dentro del
recordset devuelto por el sp? ¿Es mejor definir mensajes
de error de SQL y devolverlos como códigos de retorno o
mensajes de error? ¿Que creen ustdes?

Max Castro Vidal
Santiago de Chile
 

Leer las respuestas

#1 jose
31/08/2004 - 19:57 | Informe spam
Estoy de acuerdo con la respuesta anterior, pero seguiras
teniendo el problema para ver si el SP se ejecuto con
exito o no.

Todo SP devuelve un valor con RETURN, por default cero,
si en tú proceso validas si existe error con @@Error
despues de cada (INS, DEL o UPD) podras saber si hay
error, con esto podras devolver el valor RETURN y sabras
si el SP produjo error.

NOTA: Si una instrucción produce un error talvez las
siguientes líneas se sigan ejecutando, dependiendo de la
severidad del error, CUIDADO.

Preguntas similares