Omitir notificación de errores (II)

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.

Comparto con Adrian lo que indica, lo unico que yo no negociaria es el uso
de SP, trataria de no escribir SQL del lado del cliente ya que es muy malo a
nivel seguridad, performance!!!

Un saludo


Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Adrian D. Garcia" escribió en el mensaje
news:%

Hola Max,

Dado lo que planteas, yo replantearia la idea base y es la de tener un sp
que sea generico para manipular las operaciones de INSERT, UPDATE y DELETE
de una tabla.
Como ya habras visto si haces algo generico tienes que lidiar con una gran
variedad de situaciones que son dificiles de contemplar. Por otro lado,
desde el putno de vista de diseño, estas armando una interfaz con alto
acoplamiento ya que debes pasar como parametro el tipo de operacion a
realizar y si quieres hacer totalmente generico, tambien el nombre de la
tabla.

Mi sugerencia es la siguiente:
a) Si deseas aprechar la performance extra que le da al motor el uso de
procedimientos almacenados usa un sp para cada operacion de cada tabla.

Esto

te da el beneficio extra de perfomance y personalizacion para cada caso.
Como desventaja tendras la de escribir todo los sps, tema que se puede
solucionar un algun generador de SPs que puedas desarrollar.
b) Armar las sentencias SQL desde el cliente y manipular todo desde alli.

Saludos
Adrian D. Garcia
MCSD
NDSoft Consultoria y Desarrollo

"Max Castro V." wrote in message
news:376f01c48f66$45270dc0$
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

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004

Hola Max:
Si te sirve alguna referencia de los BOL sobre manejo de errores te
puede servir la seccion de "Handling Errors and Messages in Applications",
que habla un poquito de la arquitectura de manejo de errores.
Un "patron" de manejo de errores que uso es:
==IF EXISTS()
BEGIN
RAISERROR(...) -- Optativo
RETURN 1
END
IF EXISTS()
BEGIN
RAISERROR(...) -- Optativo
RETURN 1
END
IF EXISTS()
BEGIN
RAISERROR(...) -- Optativo
RETURN 1
END

BEGIN TRAN
INSERT ...
IF @ERROR<>0 THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END
INSERT ...
IF @ERROR<>0 THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END

COMMIT
== En la aplicacion .NET capturo las execpciones que pudiera haber por
error, por excepcion (casi siempre aunque no es lo mas rapido) o por valor
de retorno. En mi criterio este patron, es muy rapido, muy seguro, muy
escalable. Tiene el problema que es largo de escribir el codigo y exige
mayor mantenimiento de codigo al "duplicar" las reglas en Constraints
(Llaves Primarias, Checks, etc.)
Algunos miembros de este grupo (Miguel y Jesus principalmente)
consideran que es innecesario y lento hacer la primera seccion del IF EXIST
y que es mejor practica iniciar con el BEGIN TRAN y olvidarse de los IF de
antes de la transaccion. En un ambiente conectado es probable que tengan
razon y los beneficios del IF EXISTS no sean importantes.
Por cierto un solo procedimiento que manejar UPDATE/INSERT/DELETE?, para
mi gusto es mejor uno para cada operacion, aparte de eso los asistentes de
Visual Studio los hacen muy bien ;)

Saludos,



Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda


"Max Castro V." wrote in message
news:376f01c48f66$45270dc0$
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

Hola Max,

Dado lo que planteas, yo replantearia la idea base y es la de tener un sp
que sea generico para manipular las operaciones de INSERT, UPDATE y DELETE
de una tabla.
Como ya habras visto si haces algo generico tienes que lidiar con una gran
variedad de situaciones que son dificiles de contemplar. Por otro lado,
desde el putno de vista de diseño, estas armando una interfaz con alto
acoplamiento ya que debes pasar como parametro el tipo de operacion a
realizar y si quieres hacer totalmente generico, tambien el nombre de la
tabla.

Mi sugerencia es la siguiente:
a) Si deseas aprechar la performance extra que le da al motor el uso de
procedimientos almacenados usa un sp para cada operacion de cada tabla. Esto
te da el beneficio extra de perfomance y personalizacion para cada caso.
Como desventaja tendras la de escribir todo los sps, tema que se puede
solucionar un algun generador de SPs que puedas desarrollar.
b) Armar las sentencias SQL desde el cliente y manipular todo desde alli.

Saludos
Adrian D. Garcia
MCSD
NDSoft Consultoria y Desarrollo

"Max Castro V." wrote in message
news:376f01c48f66$45270dc0$
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

En realidad lo que deseo es justamente tener ese nivel de
acoplamiento en un nivel aceptable y facil de entender
para programadores de aplicaciones externos. La idea es
separar las funcionalidades de lectura y escritura. Te
ilustro un breve ejemplo

Supongamos que tenemos la tabla

IdPais Pais
-
1 Chile
2 Argentina
3 Bolivia

entonces defino los sp:

InfoPais (@IdPais int, @Pais varchar)
GestPais (@IdPais int, @Pais varchar)

Ambos sp reciben como parámetros los mismos campos de la
tabla base. El primer sp es para leer datos, devolviendo
el registro asociado a la variable @IdPais o @Pais que se
halla suministrado (si no se indicó ninguna, entonces
devuelve el listado completo).

El segundo sp está pensado para realizar escrituras en la
bd. Si @IdPais = 0 entonces creará un nuevo registro de
pais con la info de @Pais. Si @IdPais > 0 actualizará el
registro correspondiente con la info de @Pais. Finalmente,
si @IdPais < 0, entonces eliminará el registro cuyo Id
coincida con el valor positivo.

En general, este sistema permite un buén nivel de
centralización sin tener que crear tantos sp (sólo 2 por
entidad en la BD). La gestión múltiple de distintas
acciones (INSERT, UPDATE, DELETE) junto a sus respectivas
validaciones en general ya las tengo desarrolladas, sólo
me está molestando el mensaje de error para las
infracciones de identidad referencial, y este problema es
independiente a la cantidad de sp implementados. Hasta el
momento sigo con el problema del mensaje de error y
pareciera que la única solución pasa por utilizar los
mensajes generados por RAISEERROR o RETURN, con lo cual
debería cambiar el enfoque de mensajes como parte del
recordset devuelto, explicado en el mail anterior.

Max Castro Vidal
Santiago de Chile

Hola Max,

Dado lo que planteas, yo replantearia la idea base y es

la de tener un sp

que sea generico para manipular las operaciones de

INSERT, UPDATE y DELETE

de una tabla.
Como ya habras visto si haces algo generico tienes que

lidiar con una gran

variedad de situaciones que son dificiles de contemplar.

Por otro lado,

desde el putno de vista de diseño, estas armando una

interfaz con alto

acoplamiento ya que debes pasar como parametro el tipo de

operacion a

realizar y si quieres hacer totalmente generico, tambien

el nombre de la

tabla.

Mi sugerencia es la siguiente:
a) Si deseas aprechar la performance extra que le da al

motor el uso de

procedimientos almacenados usa un sp para cada operacion

de cada tabla. Esto

te da el beneficio extra de perfomance y personalizacion

para cada caso.

Como desventaja tendras la de escribir todo los sps, tema

que se puede

solucionar un algun generador de SPs que puedas

desarrollar.

b) Armar las sentencias SQL desde el cliente y manipular

todo desde alli.

Saludos
Adrian D. Garcia
MCSD
NDSoft Consultoria y Desarrollo

"Max Castro V." wrote in message
news:376f01c48f66$45270dc0$
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


.