Omitir notificación de errores (II)

Bien, mas alla de gustarme o no esta solucion lo que podrias hacer es un
generador de SPs que analize la estructura de las tablas de tu sistema y las
restricciones que tienen las mismas para verificarlas antes de cada
operacion y realizar el manejo de errores y de transacciones en forma
adecuada.

De todas formas creo que esta solucion servidra para casos de tablas y
transacciones sencillas que justamente no son los nudos de los istemas, por
lo que aqui cabe preguntarse si vale la pena invertir tanto tiempo y
esfuerzo en plantear soluciones tan genericas.


Saludos
Adrian D. Garcia
MCSD
NDSoft Consultoria y Desarrollo

"Max Castro Vidal" wrote in message
news:396401c48f8b$dd7b2dc0$
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


.