Execute

Hola!!! yo lo que uso son funciones de aplicacion, claro deberias cambiar
cosas en tu sistema :(.

Otra opcion es usar vistas por ej para lo que es consultas y dejas los SP
para el resto.

En el portal de Miguel (www.portalsql.com) escribi hace un tiempo un
articulo que explica el uso de las funciones de aplicacion, miralo un poco y
fijate si te es util.

Bye


Salu2
Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:


"ChAtEiToR" escribió en el mensaje
news:797f01c402b6$bc751670$
Estimados:

Tengo una aplicacion en VB con SQL 7.0.

Esta aplicacion maneja perfiles de usuarios que dan acceso
a los distintos menus del sistema. Cada perfil lo creo
como un Role de SQl dentro de la BD y asigno los usuarios
que corresponda a ese role.

Estos Roles tienen permisos "SOLO" a exec de
Procedimientos almacenados y "nunca" a las tablas.

El problema se me esta presentando ya que habilitamos una
opcion en el cual el usuario puede crear sus propias
consultas, generar reportes mezclando todas las opciones
del sistema, ya que cada usuario necesita sacar
información distinta.

Estos "filtros" personalizados se guardan en un campo X de
la BD y para ejecutarlo necesariamente se debe hacer un
Exec del string que generó, es aqui donde tengo el
problema, ya que el Exec de un string necesita permisos
sobre las tablas y no solo al SP que ejecuta ese Exec.

¿Alguna idea de como solucionarlo?

Lo ideal es no tener que dar permisos sobre las tablas,
solo dar persmisos a los procedimientos.

Espero sus comentarios y sugerencias.
Saludos.
Cristian.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 21/02/2004

Gracias maximiliano por tu respuesta.
Efectivamente estoy usando para este caso puntual una
vista.
El proceso es: Cuando el usuario saca su reporte
personalizado (aplicando su filtro) llamo a un sp y le
paso el código del filtro del usuario.
Este Sp ejecuta la vista que es quien rescata el string
sql que se guardo en la tabla y lo executa, o sea tiene
algo asi como

Exec ("select * from productos")

He ahí el problema por que me manda un error de acceso
denegado sobre el objeto productos.

Como la politica que aplicamos es solamente dar permisos a
los procedimientos o vistas y nunca a las tablas entonces
estoy topando en este asunto de permisos.

Segun el BOL si tu haces 2 SP's y el segundo realiaz el
Exec, verifica los permisos solo en el 1ero de estos SP
pero eso no funciona, lo he probado teniendo un SP que
solamente llame al otro que es quien realiza el Exec del
String pero no me funca.

Como te decia tengo SQL7.0 por lo tanto no puedo hacer
funciones. :-(

Alguna otra sugerencia para evitar dar permisos sobre las
tablas?

PD: Estoy buscando el articulo que mencionabas.

Desde ya muchas gracias.
Saludos.

Hola!!! yo lo que uso son funciones de aplicacion, claro

deberias cambiar

cosas en tu sistema :(.

Otra opcion es usar vistas por ej para lo que es

consultas y dejas los SP

para el resto.

En el portal de Miguel (www.portalsql.com) escribi hace

un tiempo un

articulo que explica el uso de las funciones de

aplicacion, miralo un poco y

fijate si te es util.

Bye


Salu2
-

-

Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:
-

-

"ChAtEiToR" escribió en el mensaje
news:797f01c402b6$bc751670$
Estimados:

Tengo una aplicacion en VB con SQL 7.0.

Esta aplicacion maneja perfiles de usuarios que dan acceso
a los distintos menus del sistema. Cada perfil lo creo
como un Role de SQl dentro de la BD y asigno los usuarios
que corresponda a ese role.

Estos Roles tienen permisos "SOLO" a exec de
Procedimientos almacenados y "nunca" a las tablas.

El problema se me esta presentando ya que habilitamos una
opcion en el cual el usuario puede crear sus propias
consultas, generar reportes mezclando todas las opciones
del sistema, ya que cada usuario necesita sacar
información distinta.

Estos "filtros" personalizados se guardan en un campo X de
la BD y para ejecutarlo necesariamente se debe hacer un
Exec del string que generó, es aqui donde tengo el
problema, ya que el Exec de un string necesita permisos
sobre las tablas y no solo al SP que ejecuta ese Exec.

¿Alguna idea de como solucionarlo?

Lo ideal es no tener que dar permisos sobre las tablas,
solo dar persmisos a los procedimientos.

Espero sus comentarios y sugerencias.
Saludos.
Cristian.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date:

21/02/2004

.

Gracias maximiliano por tu respuesta.
Efectivamente estoy usando para este caso puntual una
vista.
El proceso es: Cuando el usuario saca su reporte
personalizado (aplicando su filtro) llamo a un sp y le
paso el código del filtro del usuario.
Este Sp ejecuta la vista que es quien rescata el string
sql que se guardo en la tabla y lo executa, o sea tiene
algo asi como

Exec ("select * from productos")

He ahí el problema por que me manda un error de acceso
denegado sobre el objeto productos.

Como la politica que aplicamos es solamente dar permisos a
los procedimientos o vistas y nunca a las tablas entonces
estoy topando en este asunto de permisos.

Segun el BOL si tu haces 2 SP's y el segundo realiaz el
Exec, verifica los permisos solo en el 1ero de estos SP
pero eso no funciona, lo he probado teniendo un SP que
solamente llame al otro que es quien realiza el Exec del
String pero no me funca.

Como te decia tengo SQL7.0 por lo tanto no puedo hacer
funciones. :-(

Alguna otra sugerencia para evitar dar permisos sobre las
tablas?

PD: Estoy buscando el articulo que mencionabas.

Desde ya muchas gracias.
Saludos.

Hola!!! yo lo que uso son funciones de aplicacion, claro

deberias cambiar

cosas en tu sistema :(.

Otra opcion es usar vistas por ej para lo que es

consultas y dejas los SP

para el resto.

En el portal de Miguel (www.portalsql.com) escribi hace

un tiempo un

articulo que explica el uso de las funciones de

aplicacion, miralo un poco y

fijate si te es util.

Bye


Salu2
-

-

Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:
-

-

"ChAtEiToR" escribió en el mensaje
news:797f01c402b6$bc751670$
Estimados:

Tengo una aplicacion en VB con SQL 7.0.

Esta aplicacion maneja perfiles de usuarios que dan acceso
a los distintos menus del sistema. Cada perfil lo creo
como un Role de SQl dentro de la BD y asigno los usuarios
que corresponda a ese role.

Estos Roles tienen permisos "SOLO" a exec de
Procedimientos almacenados y "nunca" a las tablas.

El problema se me esta presentando ya que habilitamos una
opcion en el cual el usuario puede crear sus propias
consultas, generar reportes mezclando todas las opciones
del sistema, ya que cada usuario necesita sacar
información distinta.

Estos "filtros" personalizados se guardan en un campo X de
la BD y para ejecutarlo necesariamente se debe hacer un
Exec del string que generó, es aqui donde tengo el
problema, ya que el Exec de un string necesita permisos
sobre las tablas y no solo al SP que ejecuta ese Exec.

¿Alguna idea de como solucionarlo?

Lo ideal es no tener que dar permisos sobre las tablas,
solo dar persmisos a los procedimientos.

Espero sus comentarios y sugerencias.
Saludos.
Cristian.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date:

21/02/2004

.

Hola!! yo no recuerdo si las funciones de aplicacion estan en la version 7.0
:(.

Ahora francamente no es bueno que los usuarios tengan la posibilidad de
armar sus Querys, tu DBA no se pondra nada contento.

Lo ideal es que si la herramienta tenga esa opcion pero que exista alguien
de sistemas y con conocimientos de SQL para hacerlo.

Sino te vas a encontrar con muchos problemas de performance.

Ahora lo que podes hacer es que el usuario arme una vista y sea propietario
de la misma, para armar la vista solo necesita conocer las estructuras
verdad? para ello podrias armar un Store que retorne las estructuras por ej.

En la version 7 no se si existia las vistas INFORMATION_SCHEMA, pero de ser
asi podrias ver las columnas por ej de esta forma

Select * from information_schema.columns where table_name='tutabla'

con esto que arme los querys y guarde una vista con propietario al usuario.

Pero como dije antes, esto no me gusta que los usuarios anden armando Querys
sino un dia te vas a levantar con que el motor esta a full y te vas a querer
matar, nunca falta alguno que te hace un Select * From compras y esto tarda
6 dias ;-)

Suerte





Salu2
Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:


"ChAtEiToR" escribió en el mensaje
news:4d4a01c402ba$b8330320$
Gracias maximiliano por tu respuesta.
Efectivamente estoy usando para este caso puntual una
vista.
El proceso es: Cuando el usuario saca su reporte
personalizado (aplicando su filtro) llamo a un sp y le
paso el código del filtro del usuario.
Este Sp ejecuta la vista que es quien rescata el string
sql que se guardo en la tabla y lo executa, o sea tiene
algo asi como

Exec ("select * from productos")

He ahí el problema por que me manda un error de acceso
denegado sobre el objeto productos.

Como la politica que aplicamos es solamente dar permisos a
los procedimientos o vistas y nunca a las tablas entonces
estoy topando en este asunto de permisos.

Segun el BOL si tu haces 2 SP's y el segundo realiaz el
Exec, verifica los permisos solo en el 1ero de estos SP
pero eso no funciona, lo he probado teniendo un SP que
solamente llame al otro que es quien realiza el Exec del
String pero no me funca.

Como te decia tengo SQL7.0 por lo tanto no puedo hacer
funciones. :-(

Alguna otra sugerencia para evitar dar permisos sobre las
tablas?

PD: Estoy buscando el articulo que mencionabas.

Desde ya muchas gracias.
Saludos.

Hola!!! yo lo que uso son funciones de aplicacion, claro

deberias cambiar

cosas en tu sistema :(.

Otra opcion es usar vistas por ej para lo que es

consultas y dejas los SP

para el resto.

En el portal de Miguel (www.portalsql.com) escribi hace

un tiempo un

articulo que explica el uso de las funciones de

aplicacion, miralo un poco y

fijate si te es util.

Bye


Salu2
-

-

Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:
-

-

"ChAtEiToR" escribió en el mensaje
news:797f01c402b6$bc751670$
Estimados:

Tengo una aplicacion en VB con SQL 7.0.

Esta aplicacion maneja perfiles de usuarios que dan acceso
a los distintos menus del sistema. Cada perfil lo creo
como un Role de SQl dentro de la BD y asigno los usuarios
que corresponda a ese role.

Estos Roles tienen permisos "SOLO" a exec de
Procedimientos almacenados y "nunca" a las tablas.

El problema se me esta presentando ya que habilitamos una
opcion en el cual el usuario puede crear sus propias
consultas, generar reportes mezclando todas las opciones
del sistema, ya que cada usuario necesita sacar
información distinta.

Estos "filtros" personalizados se guardan en un campo X de
la BD y para ejecutarlo necesariamente se debe hacer un
Exec del string que generó, es aqui donde tengo el
problema, ya que el Exec de un string necesita permisos
sobre las tablas y no solo al SP que ejecuta ese Exec.

¿Alguna idea de como solucionarlo?

Lo ideal es no tener que dar permisos sobre las tablas,
solo dar persmisos a los procedimientos.

Espero sus comentarios y sugerencias.
Saludos.
Cristian.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date:

21/02/2004

.

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 21/02/2004

A ver.. no quice entrar en muchos detalles de sus querys
personalizados, pero para no confunfdir explicaré un
poquito como funciona el sistemita

Primero que nada como la aplicación maneja perfiles, solo
algunos usuarios tienen acceso a los famosos filtros (a lo
mas 10 de 1000 usuarios)

El hecho de que hagan sus propias querys era una forma de
explicar que ellos pueden elegir que consultar, pero ellos
no ven nada de tablas, ni de estructuras, los usuarios no
tienen idea que hay detras de una pantallita, ni menos de
donde saca la info.

Aca tenemos por lo menos 100 reportes (en este sistema) en
Crystal reports que sacan diferente información, pero como
estos reportes siempre estan encasillados en los
requerimientos y al parecer a la gallada le gusto eso
de "reportes" se comenzaron a entusiasmar, y ciertos
usuarios comenzaron a pedir reportes a medidas y comenzó
la invación de pedidos de reportes, muchos de estos
reportes eran practicamente iguales a los existentes salvo
con algun otro filtro adicional, por ejemplo existe un
reporte de clientes con job abiertos o cerrados en X
periodo de tiempo, que es comun para todos, pero ciertos
usuarios necesitaban saber ademas de estos clientes con
job cerrados o abiertos que cumpieran con X sector
industrial.

Aqui nacio la idea de permitir a los usuarios generar su
propios reportes

Espero haya quedado un poco mas claro el tema, solo queria
dejar en claro que no es algo asi como que seleccione
todos los campos de una tabla monstruosa, o que vean en la
aplicacion una especie de Query Analyser donde escriban
codigo T-SQL, eso no pasara ya que solo se agregan mas
filtros a los ya existentes.. o sea en resumen se le
agrega una condicion where mas a los ya existentes.

El usuario solo dice "ok, a este reporte (ya existente),
necesito ademas que me saque la info pero solo aquellos
clientes que esten en la region metropolitana y que
pertenezcan al sector minero"... por ejemplo. Este tipo de
cosas hacen, pero con una interfaz amigable, nada de sql
para los usuarios, por lo tanto el universo de registros
se reduce al aplicar mas condiciones a las ya existentes.

Entonces sacamos el sql del reporte elegido (ya existente)
y le agregamos las condicionantes que tiene su filtro. Por
lo tanto no se demora mas, mas bien se demora mucho menos
en la mayoria de los casos.

¿Me explico?

A todo esto el DBA es mi jefe asiesque no esta tan
enojado... creo. :-)

Volviendo a mi problema, este se me produce justamente al
concatenar ambos sql's y realizar el EXEC, ya que el exec
necesita permisos sobre la tabla y eso me gustaría
evitarlo, ahoras si no es posible, tendremos que dar
permisos sobre las tablas, aunque sería nuestra última
opción.

Bueno, espero me puedan ayudar a buscar una solución.
Saludos y gracias por tu ayuda Maximiliano.


Cristian.

Hola!! yo no recuerdo si las funciones de aplicacion

estan en la version 7.0

:(.

Ahora francamente no es bueno que los usuarios tengan la

posibilidad de

armar sus Querys, tu DBA no se pondra nada contento.

Lo ideal es que si la herramienta tenga esa opcion pero

que exista alguien

de sistemas y con conocimientos de SQL para hacerlo.

Sino te vas a encontrar con muchos problemas de

performance.

Ahora lo que podes hacer es que el usuario arme una vista

y sea propietario

de la misma, para armar la vista solo necesita conocer

las estructuras

verdad? para ello podrias armar un Store que retorne las

estructuras por ej.

En la version 7 no se si existia las vistas

INFORMATION_SCHEMA, pero de ser

asi podrias ver las columnas por ej de esta forma

Select * from information_schema.columns where

table_name='tutabla'

con esto que arme los querys y guarde una vista con

propietario al usuario.

Pero como dije antes, esto no me gusta que los usuarios

anden armando Querys

sino un dia te vas a levantar con que el motor esta a

full y te vas a querer

matar, nunca falta alguno que te hace un Select * From

compras y esto tarda

6 dias ;-)

Suerte





Salu2
-

-

Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:
-

-

"ChAtEiToR" escribió en el mensaje
news:4d4a01c402ba$b8330320$
Gracias maximiliano por tu respuesta.
Efectivamente estoy usando para este caso puntual una
vista.
El proceso es: Cuando el usuario saca su reporte
personalizado (aplicando su filtro) llamo a un sp y le
paso el código del filtro del usuario.
Este Sp ejecuta la vista que es quien rescata el string
sql que se guardo en la tabla y lo executa, o sea tiene
algo asi como

Exec ("select * from productos")

He ahí el problema por que me manda un error de acceso
denegado sobre el objeto productos.

Como la politica que aplicamos es solamente dar permisos a
los procedimientos o vistas y nunca a las tablas entonces
estoy topando en este asunto de permisos.

Segun el BOL si tu haces 2 SP's y el segundo realiaz el
Exec, verifica los permisos solo en el 1ero de estos SP
pero eso no funciona, lo he probado teniendo un SP que
solamente llame al otro que es quien realiza el Exec del
String pero no me funca.

Como te decia tengo SQL7.0 por lo tanto no puedo hacer
funciones. :-(

Alguna otra sugerencia para evitar dar permisos sobre las
tablas?

PD: Estoy buscando el articulo que mencionabas.

Desde ya muchas gracias.
Saludos.

Hola!!! yo lo que uso son funciones de aplicacion, claro

deberias cambiar

cosas en tu sistema :(.

Otra opcion es usar vistas por ej para lo que es

consultas y dejas los SP

para el resto.

En el portal de Miguel (www.portalsql.com) escribi hace

un tiempo un

articulo que explica el uso de las funciones de

aplicacion, miralo un poco y

fijate si te es util.

Bye


Salu2

-

-

Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:

-

-

"ChAtEiToR" escribió en el mensaje
news:797f01c402b6$bc751670$
Estimados:

Tengo una aplicacion en VB con SQL 7.0.

Esta aplicacion maneja perfiles de usuarios que dan

acceso

a los distintos menus del sistema. Cada perfil lo creo
como un Role de SQl dentro de la BD y asigno los usuarios
que corresponda a ese role.

Estos Roles tienen permisos "SOLO" a exec de
Procedimientos almacenados y "nunca" a las tablas.

El problema se me esta presentando ya que habilitamos una
opcion en el cual el usuario puede crear sus propias
consultas, generar reportes mezclando todas las opciones
del sistema, ya que cada usuario necesita sacar
información distinta.

Estos "filtros" personalizados se guardan en un campo X

de

la BD y para ejecutarlo necesariamente se debe hacer un
Exec del string que generó, es aqui donde tengo el
problema, ya que el Exec de un string necesita permisos
sobre las tablas y no solo al SP que ejecuta ese Exec.

¿Alguna idea de como solucionarlo?

Lo ideal es no tener que dar permisos sobre las tablas,
solo dar persmisos a los procedimientos.

Espero sus comentarios y sugerencias.
Saludos.
Cristian.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system

(http://www.grisoft.com).

Version: 6.0.593 / Virus Database: 376 - Release Date:

21/02/2004

.

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date:

21/02/2004

.