Será buena idea que el usuario pueda hacer querys personalizadas?

[MartinS]

Hola: Yo hace un tiempo comencé a agregar un formulario al que accedo por contraseña que contiene un memo, un boton de ejecutar, un dbgrid y un boton para exportar a excel los datos ya que siempre necesitaban algun tipo de informe que no habia sido diseñado y/o solicitado en la fase de analisis y desarrollo. De esta manera soluciono no tener que seguir agregandole cosas que, como estas diciendo, tal vez la usen una sola vez.-

Saludos

[[fjcg02]]

Me inclino por la solución de Roman, que pueda ejecutar vistas, las que tú decidas.

En alguna ocasión he realizado una solución parecida. Añado una tabla con una pequeña descripción y la sql que quiero que se ejecute. Con un botén de ejecutar cargo la sentencia en los componentes del formulario y se ejecutan. También suele ser necesario incluir los tipos o máscaras de los campos. Para añadir nuevas posibilidades al usuario, sólo hay que incluir registros en esa tabla. Obviamente, esta tabla no puede manejarla el usuario. Si te pide algo nuevo, le pasas el procediminto para insertar un nuevo registro en esa tabla y que pueda ejecutarlo. Si luego él puede ordenar, sacar totales, filtrar, etc, ya tienes la solución.

Saludos

[Casimiro Noteví]

Yo siempre añado una opción para ejecutar SQLs.
Incluso con un mantenimiento de esos sqls, se pueden guardar, ponerle una descripción de lo que hace, volver a ejecutarlos, borrarlos, modificarlos, etc.
Cada una almacena la fecha de creación, de ejecución, etc. en fin, un mantenimiento muy completo.
Se informa que esas sentencias a ejecutar pueden ser peligrosas si no saben lo que están haciendo y, además, se mantiene un registro de los sqls ejecutados por si acaso luego vienen con un "se han perdido las ventas de todo un año y yo no he tocado nada".
Miro la tabla de sqls ejecutados y veo una que dice: "delete from tbventas where year=2010"
Por supuesto, cuando se ha ejecutado la sentencia aparecen al terminar los botones "confirmar" y "cancelar", que hacen 'commit' y 'rollback', que es ahí donde al usuario le debería de caer las gotas de sudor por la frente pensando si le da a uno o a otro botón
Básicamente se usan para procesos repetitivos que ha pedido algún cliente y no merece la pena añadir un módulo para ello porque nadie más lo usaría.
Y también para cosas "nuestras", arreglos de meteduras de pata por parte del usuario, etc.

[[newtron]]

Empezado por Casimiro Notevi

Yo siempre añado una opción para ejecutar SQLs.
Incluso con un mantenimiento de esos sqls, se pueden guardar, ponerle una descripción de lo que hace, volver a ejecutarlos, borrarlos, modificarlos, etc.
Cada una almacena la fecha de creación, de ejecución, etc. en fin, un mantenimiento muy completo.
Se informa que esas sentencias a ejecutar pueden ser peligrosas si no saben lo que están haciendo y, además, se mantiene un registro de los sqls ejecutados por si acaso luego vienen con un "se han perdido las ventas de todo un año y yo no he tocado nada".
Miro la tabla de sqls ejecutados y veo una que dice: "delete from tbventas where year=2010"
Por supuesto, cuando se ha ejecutado la sentencia aparecen al terminar los botones "confirmar" y "cancelar", que hacen 'commit' y 'rollback', que es ahí donde al usuario le debería de caer las gotas de sudor por la frente pensando si le da a uno o a otro botón
Básicamente se usan para procesos repetitivos que ha pedido algún cliente y no merece la pena añadir un módulo para ello porque nadie más lo usaría.
Y también para cosas "nuestras", arreglos de meteduras de pata por parte del usuario, etc.

(¿se nota que tengo poco tiempo para escribir mis respuestas?)