ejecutar procedimiento almacenado

"Luis Mata" escribió en el mensaje
news:

Hay alguna otra forma de poder hacer esto,

el procedure recibe como parametro el nombre de la base de datos @nombd
declare @ejecuta varchar(100)
set @ejecuta = 'select * from '+@nombd+'.dbo.ventas'
exec (@ejecuta)

algo mas corto ya que ahi no se ve muchos problemas pero cuando son mas
variables y condiciones se pone un poco pesado.

Hola, Luis Mata:

A ver: si tienes n elementos variables, debes armar una sentencia de SQL
dinámico con n sustituciones, y luego llamarla mediante exec(@ejecuta) o
mediante una llamada a sp_executesql. Es una cuestión de aritmética
elemental.

A veces, por evitar escribir 10 SPs, uno cree que si escribe uno solo, lo
suficientemente complejo como para manejar las diez situaciones, se está
ganando en eficiencia.

Pero es mentira: por lo general el resultado es un código torpe, inseguro,
difícil de comprender y en consecuencia propenso a errores.

Pero eso es cuestión de estilo -y bastante independiente del lenguaje: quien
lo hace con Transact SQL, lo hace con Java o con C.

Y tambien puedes considerar la posibilidad de escribir el código
directamente desde tu aplicación: cuando tienes sentencias que se arman
dinámicamente, esto es una opción mucho más sensata que generarlas en el
servidor. Y por lo general, si lo llamas desde un lenguaje de programación,
éste tiene muchos más recursos de manejo de cadenas que el propio Transact
SQL.


Salud!

Gracias
Creo que el problema principal es que mis sistema trabaja con VPN con sedes
remotas ubicadas en distintos distritos. algunos con 512 kbps otros de 256
kbps.
se realizan trnsacciones en linea, pero cuando se quiere hacer un analisis
de ventas para poder hacer compras segun lo vendido se hace en un rango de 7
meses antes y para poder tener mas clara la cosa y no estar consbrestock
generar se reuqiere que tener el promedio de ventas de todas las tiendas (8)
cada uno son su stock.
con vistas te imaginas que cada Adm de tienda tenga que llevar los datos de
los 7 meses por cada tienda y consolidarlo localmente se come todo el ancho
de banda, aqui el caso es que el servidor lo mastique y les envie solo los
resultados.
y al ser 8 sedes quiero hacer todo ese codigo en una bd maestro osea con
create #tabla ... asi centralizaria mi codigo
claro si fuere posible lo que no quiero es tener procedures que me redunden
en las bds


Att
Luis Mata Figueroa
Área Informática
Centro Cerámico Las Flores SAC
RPC: 993597297
TEL: 6174613


"Leonardo Azpurua" <l e o n a r d o [arroba] m v p s [punto] o r g> escribió
en el mensaje news:

"Luis Mata" escribió en el mensaje
news:

tienes razon en algunas cosas.
pero no solo es un select el que hago en el procedure, lo que hago es
recorrer 8 bd extraer informacion consolidarla usando condiciones y
cursores, si fuera un select nada mas no seria problema, lo que quiero
hacer es crear el procedure en un bd maestro donde coloque todos los
procedures cosa que solo ahi modifico cualquier cosa para las 8 bds.
- el codigo si es dificil y extenso por eso era mi pregunta para poder
simplificarlo
- asi no se tendria que estar dando alter bd por bd
-alguna otra forma de poder tener centralizada los procedures que se
ejecuten en la bd donde el usuario este conectado, obviamente que no al
maestro si no donde esta la informacion digamos bdtienda1 y la extraiga y
lam muestre

Hola, Luis:

Tienes una cantidad de recursos que tal vez no estás tomando en cuenta.

Por ejemplo, puedes usar vistas para obtener acceso a las tablas
consolidadas. Puedes organizar el codigo de un SP en varios. Puedes crear
funciones que te devuelvan cursores. Puedes anidar SPs. Puedes utilizar
tablas temporales.

Como no se cual es el problema, no se como ayudarte en concreto. Sólo
puedo recordarte los principios generales.

Y por último (y esto es una opinión absolutamente controversial): la
diferencia entre la capacidad de proceso del servidor y la de las
estaciones de trabajo por lo general no es tan inmensa como para
desaprovechar la segunda. ¿Por qué no transfieres parte de la lógica de
ese procedimiento complejo a la aplicación?

Salud!

tienes razon en algunas cosas.
pero no solo es un select el que hago en el procedure, lo que hago es
recorrer 8 bd extraer informacion consolidarla usando condiciones y
cursores, si fuera un select nada mas no seria problema, lo que quiero hacer
es crear el procedure en un bd maestro donde coloque todos los procedures
cosa que solo ahi modifico cualquier cosa para las 8 bds.
- el codigo si es dificil y extenso por eso era mi pregunta para poder
simplificarlo
- asi no se tendria que estar dando alter bd por bd
-alguna otra forma de poder tener centralizada los procedures que se
ejecuten en la bd donde el usuario este conectado, obviamente que no al
maestro si no donde esta la informacion digamos bdtienda1 y la extraiga y
lam muestre

Att
Luis Mata Figueroa
Área Informática
Centro Cerámico Las Flores SAC
RPC: 993597297
TEL: 6174613


"Leonardo Azpurua" <l e o n a r d o [arroba] m v p s [punto] o r g> escribió
en el mensaje news:

"Luis Mata" escribió en el mensaje
news:

Hay alguna otra forma de poder hacer esto,

el procedure recibe como parametro el nombre de la base de datos @nombd
declare @ejecuta varchar(100)
set @ejecuta = 'select * from '+@nombd+'.dbo.ventas'
exec (@ejecuta)

algo mas corto ya que ahi no se ve muchos problemas pero cuando son mas
variables y condiciones se pone un poco pesado.

Hola, Luis Mata:

A ver: si tienes n elementos variables, debes armar una sentencia de SQL
dinámico con n sustituciones, y luego llamarla mediante exec(@ejecuta) o
mediante una llamada a sp_executesql. Es una cuestión de aritmética
elemental.

A veces, por evitar escribir 10 SPs, uno cree que si escribe uno solo, lo
suficientemente complejo como para manejar las diez situaciones, se está
ganando en eficiencia.

Pero es mentira: por lo general el resultado es un código torpe, inseguro,
difícil de comprender y en consecuencia propenso a errores.

Pero eso es cuestión de estilo -y bastante independiente del lenguaje:
quien lo hace con Transact SQL, lo hace con Java o con C.

Y tambien puedes considerar la posibilidad de escribir el código
directamente desde tu aplicación: cuando tienes sentencias que se arman
dinámicamente, esto es una opción mucho más sensata que generarlas en el
servidor. Y por lo general, si lo llamas desde un lenguaje de
programación, éste tiene muchos más recursos de manejo de cadenas que el
propio Transact SQL.


Salud!

"Luis Mata" escribió en el mensaje
news:

tienes razon en algunas cosas.
pero no solo es un select el que hago en el procedure, lo que hago es
recorrer 8 bd extraer informacion consolidarla usando condiciones y
cursores, si fuera un select nada mas no seria problema, lo que quiero
hacer es crear el procedure en un bd maestro donde coloque todos los
procedures cosa que solo ahi modifico cualquier cosa para las 8 bds.
- el codigo si es dificil y extenso por eso era mi pregunta para poder
simplificarlo
- asi no se tendria que estar dando alter bd por bd
-alguna otra forma de poder tener centralizada los procedures que se
ejecuten en la bd donde el usuario este conectado, obviamente que no al
maestro si no donde esta la informacion digamos bdtienda1 y la extraiga y
lam muestre

Hola, Luis:

Tienes una cantidad de recursos que tal vez no estás tomando en cuenta.

Por ejemplo, puedes usar vistas para obtener acceso a las tablas
consolidadas. Puedes organizar el codigo de un SP en varios. Puedes crear
funciones que te devuelvan cursores. Puedes anidar SPs. Puedes utilizar
tablas temporales.

Como no se cual es el problema, no se como ayudarte en concreto. Sólo puedo
recordarte los principios generales.

Y por último (y esto es una opinión absolutamente controversial): la
diferencia entre la capacidad de proceso del servidor y la de las estaciones
de trabajo por lo general no es tan inmensa como para desaprovechar la
segunda. ¿Por qué no transfieres parte de la lógica de ese procedimiento
complejo a la aplicación?

Salud!

"Luis Mata" escribió en el mensaje
news:uPj%

Gracias
Creo que el problema principal es que mis sistema trabaja con VPN con
sedes remotas ubicadas en distintos distritos. algunos con 512 kbps otros
de 256 kbps.
se realizan trnsacciones en linea, pero cuando se quiere hacer un analisis
de ventas para poder hacer compras segun lo vendido se hace en un rango de
7 meses antes y para poder tener mas clara la cosa y no estar consbrestock
generar se reuqiere que tener el promedio de ventas de todas las tiendas
(8) cada uno son su stock.
con vistas te imaginas que cada Adm de tienda tenga que llevar los datos
de los 7 meses por cada tienda y consolidarlo localmente se come todo el
ancho de banda, aqui el caso es que el servidor lo mastique y les envie
solo los resultados.
y al ser 8 sedes quiero hacer todo ese codigo en una bd maestro osea con
create #tabla ... asi centralizaria mi codigo
claro si fuere posible lo que no quiero es tener procedures que me
redunden en las bds

Hola.

¿Las ocho sucursales trabajan sobre 8 BBDD diferentes en un servidor
central?

Con limitaciones de ancho de banda, tiene sentido colocar todas las
operaciones de consolidación y filtrado del lado del servidor. Y las vistas
pueden ayudarte a eso.

Una vista puede ser algo como:

CREATE VIEW DetallesVentasConsolidados AS
SELECT 'SUC1' As Sucursal, * FROM bd1.dbo.DetallesVenta
UNION SELECT 'SUC2', * FROM bd2.dbo.DetallesVenta
...
UNION SELECT 'SUCn´, * FROM bdn.dbo.DetallesVenta

y eso te permitiría escribir en tu SP algo como

SELECT Sucursal, Item, Sum(Cantidad)
FROM DetallesVentasConsolidados
WHERE ...
GROUP BY Sucursal,

eliminando la necesidad de acceder explícitamente a las diferentes BBDD
desde el SP (lo que no sé es que tal sea ese método en términos de
rendimiento en comparación con otros).

Las vistas y cualquier otro recurso que necesites para la consolidación de
información bien pueden residir en la BBDD que almacena los datos de la sede
principal, o bien en una BBDD de consolidación, independiente de cualquier
sucursal. Los procesos, en cualquier caso, se ejecutarán todos del lado del
servidor.

Ahora tengo alguna información adicional acerca de tu problema (las
limitaciones de ancho de banda), pero eso no es suficiente para salir del
nivel de las generalidades.


Salud!