Hola a todos:

necesito crear un procedure que seleccione determinadas lineas de una tabla,
ejecute ciertos calculos sobre estas lineas para saber si son o no
adecuadas, borre algunas y pase el resultado a otra tabla, todo ello sin
alterar la primera tabla

dicho procedure (llamemosle interno) sera llamado desde otro procedure
(llamemosle externo) el cual es utilizado por el usuario y tiene parametros
de entrada y uno de salida

mis dudas :

(A) - procedure ejecutado desde otro procedure

es posible hacer que el procedure externo no espere a que el interno acabe
para darle la salida al usuario ?? (decir que la salida al usuario de nada
depende del resultado del procedure interno)

el caso es devido a que el externo dura unos segundos en ejecutarse,
mientras que el inerno puede llegar a durar 5-6 minutos


(B) - declaracion dinamica de una variable tabla en un procedure

en el procedure interno, mi idea es de crear una variable @tabla donde
insertar las lineas necesarias de la primera tabla, hacer en esta variable
los cambios oportunos, e insertar a la tabla destino desde @tabla

decir que la tabla origuen y destino tiene (y tendran siempre) la misma
definicion en cuanto a columnas y key columnas, pero esta puede cambiar (en
ambas tablas a la vez) y no quisiera tener que modificar el procedure

a lo que se me presentan dos soluciones :
1 - crear @tabla solamente con los campos key para realizar los calculos
(los campos key son suficientes para los calculos) y hacer la insercion
referenciando (join) a la tabla origen
2 - declarar de forma "dinamica" la definicion de @tabla, para que si la
tabla origen cambia, no tener que alterar el procedure

mi pregunta es, se puede hacer esta declaracion dinamica ??

temo que la solucion numero 1 es mas compleja de realizar y posiblemente de
mantener despues, y no se que tal se llevara con el rendimiento, aunque a
bote pronto para mas estable, realmente lo es ??


gracias por adelantado a todos/as los que haceis que esos foros funcionen

En cuanto a la primera pregunta puedes echar un vistazo a este enlace,
http://groups.google.es/group/micros...owse_frm/threa
d/d8f9cc111c79b442/7ffe84bc858fe1e0?lnk=st&q=asincrono+group:microsof t.publi
c.es.sqlserver&rnum=2&hl=es#7ffe84bc858fe1e0, en donde el maestro Fernando
G. Guerrero presenta un ejemplo de una situación muy parecida a lo que
necesitas. Está hecho en VB6.0, pero estoy seguro que en .NET (si es lo que
estás usando ahora) hay algo similar.

En cuanto a la segunda pregunta, yo no usaría esa declaración dinámica
cuando puedes conseguir lo mismo haciendo luego un JOIN. No veo por qué
tiene que ser más complicado el mantenimiento... Con la ejecución dinámica
no te queda más remedio que usar tablas temporales globales, porque las
variable de tipo TABLE (al igual que las temporales no globales) sólo están
disponibles para el ámbito de ejecución; es decir, que sólo la verías dentro
de esa ejecución dinámica, y el uso de tablas globales trae complicaciones
puesto que están disponibles para todo el sistema (por eso son globales,
verdad?)

--

Hola Carlos

sobre la primera pregunta le hechare un vistazo
adelantar que yo "ofrezco" el procedure externo sin que me importe mucho
como lo usan, hoy por hoy hay dos applicaciones utilizandolo, una basada en
web (que si creo que es en .net) y la otra desde un projecto acess
el procedure externo esta implementado y funciona, pero los datos tienen que
ser tratados para pasarlos a esta segunda tabla.
Se me ocurrio esta idea en contraposicion a hacer una tabla con "things to
do" (inserciones en el procedure externo) y ser el segundo procedure
(interno) el que se encarge de leerla y actuar tal que, y ser ejecutado este
cada hora por ejemplo. Asi me evito el hacer jobs y tener que monitorearlos.
Con lo cual no deveria ser muy dependiente del lenguaje en el que este
escrita la aplicacion, no ?

la segunda opcion no se si te entiendo muy bien:
te refrieres que para declarar una tabla dinamica lo he de hacer con una
tabla "fisica" y no con una variable tabla ??,
si es asi te he entendido, gracias por aclararmelo e intentare hacerlo con
el join


muchas gracias por la respuesta, muy buena respuesta


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> wrote in message
news:2008
[..]

Hola Carlos:

un pequeño apunte, he estado leyendo el ejemplo al que te refieres y no veo
cual es la relaccion,
quizas no me he espresado bien, pongo en ejemplo

la base de datos almacena cierta informacion sobre clientes, recibiendo
numerosas lineas para cada cliente
en una tabla esta el listado de clientes con su id, etc...
en otra tabla (y mediante un sp) se alamcena la informacion que se va
recibiendo de cada cliente, este proceso puede durar minutos, horas... no
importa, pero no es instantaneo

asi la aplicacion (web, acess) deve funcionar tal que :
- order de "abrir" el cliente, que le dice al sql server que se van a
empezar a enviar datos para ese cliente, recibo nombre de usuario, asi si
alguien mas intenta abrirlo le dice que esta bloqueado
- recepcion de datos, una o mil lineas, un segundo o varia horas
- orden de "cerrar" el cliente, con lo cual marco como actualizado el
cliente y queda a esperas de recibir nuevos datos en un futuro, la
aplicacion recibe que el cliente ha sido "cerrado" y que se procesaran los
cambios, nada mas

ahora es cuando entra el segundo (interno) procedimiento, pues los datos que
han sido introducidos tienen que ser "limpiados" antes de exportarlos a la
siguiente tabla, pero a si vez deben seguir en la tabla en la que fueron
introducidos para posteriores consultas, etc...

es por eso la idea de una tabla "things to do" pero quiero evitarme el tener
un job ejecutandose cada hora para comprobar que clientes han sido
actualizados. Por eso pense en añadir una llamada desde el procedimiento
externo, pero no quiero que este se detenga hasta que el interno finalize

si aun no me explico bien dimelo, (hasta a mi se me hace confuso leerlo)

gracias por adelantado


".·:m·a·r·l·a:·." <m.a.r.l.a> wrote in message
news:2792
[..]

Perdona la tardanza, uno ha estado ocupado hoy...

Bueno, un poco enrevesado sí que está, pero tengo una duda. Ese segundo
procedimiento que tú llamas interno, ¿no se puede realizar según se
recepcionan los datos del cliente?. De ese modo nos quedaríamos con un único
procedimiento que se encargaría de mantener esa tabla, digamos, "sucia" que
se usará para posteriores consultas, y también mantendría la tabla final...

No creo que se pueda hacer así porque supongo que si no, ya lo habrías
pensado, pero con las indicaciones que me has pasado no veo por qué no es
posible...

--