Ventana de Busqueda

[escorpionrojo43]

Empezado por Caro

Hola, el error yo creo que te da por el OnClose de tu formulario de busqueda:

Código Delphi [-]
 //liberas tu formulario antes de tiempo
 //comenta esta linea y prueba
 freeandnil(FBuscaPaciente);

Saluditos

efectivamente ese era el problema
Gracias caro.

[escorpionrojo43]

Casimiro
me ha causado una gran inquietud lo que dijiste podrias decirme lo peligroso del codigo por favor?

[[mightydragonlor]]

Empezado por escorpionrojo43

Casimiro
me ha causado una gran inquietud lo que dijiste podrias decirme lo peligroso del codigo por favor?

No sé que esté pensando Casimiro, pero de algo si estoy seguro, 1 - SQL Injection, 2 - Bajo rendimiento, ya que cada vez que mandas a un motor una consulta SQL hace que el motor tenga un rendimiento mucho menor que si ejecutaras un procedimiento almacenado o vista.

[[Delphius]]

Bueno, es peligroso en 1er lugar porque es muy prospenso a una injección de SQL. En este hilo se ha comentado al respecto.

Saludos,

[roman]

Empezado por mightydragonlor

2 - Bajo rendimiento, ya que cada vez que mandas a un motor una consulta SQL hace que el motor tenga un rendimiento mucho menor que si ejecutaras un procedimiento almacenado o vista.

A ver, esta parte no me queda clara. ¿Que los motores de bases de datos no están precisamente para mandarles consultas? En este caso -buscar pacientes- ¿cómo nos ayudaría un procedimiento almacenado?

// Saludos

[[mightydragonlor]]

Empezado por roman

A ver, esta parte no me queda clara. ¿Que los motores de bases de datos no están precisamente para mandarles consultas? En este caso -buscar pacientes- ¿cómo nos ayudaría un procedimiento almacenado?

// Saludos

No es que no estén preparados, pero a un nivel mas técnico, cuando mandas un Select bla bla bla esta instrucción debe ser parseada, estudiada para conseguir un plan de ejecución óptimo y luego ejecutada, cuando creas un procedimiento almacenado o una vista, lo anterior solo se hace una vez, cuando se crea, el resto de las veces ya no tiene por que hacerlo, por que ya lo tiene definido, pero si se hace algún cambio en índices, cuando se ejecute nuevamente la vista o procedimiento almacenado, se vuelve a generar el plan de ejecución y se sigue usando siempre, excepto si vuelve a cambiar algún índice, pero cuando mandas un select directo a la base de datos, esto se hace siempre, imagina que tienes 1000 usuario simultaneos haciendo esto, cada minuto, la diferencia es salvaje, espero te haya ayudado en algo, el tema es bien complejo y muy extenso, pero traté de hacerlo de la mejor manera.

[roman]

Gracias. Entonces, ¿lo recomendado es llenar la base de procedimientos almacenados e invocarlos desde la aplicación cliente?

// Saludos

[[mightydragonlor]]

Empezado por roman

Gracias. Entonces, ¿lo recomendado es llenar la base de procedimientos almacenados e invocarlos desde la aplicación cliente?

// Saludos

Actualmente es lo que hago, estoy haciendolo en Oracle, MS-SQL y Firebird, con muy buenos resultados, teniendo una ventaja adicional al rendimiento, cuando debo hacer un cambio en la lógica del procedimiento almacenado, sin cambiar parámetros de entrada y salida, no tengo que generar ningún cambio en el programa =)

[[Delphius]]

Empezado por roman

Gracias. Entonces, ¿lo recomendado es llenar la base de procedimientos almacenados e invocarlos desde la aplicación cliente?

// Saludos

No me atrevería a asegurar que todas las consultas se llevaran a un procedimiento almacenado y/o vistas en el lado servidor como para utilizar tan libre la palabra "llenar" pero... en lo posible yo diría que hay que dejarle al motor las cosas que sabe hacer bien.

Y justamente si tienes consultas estáticas, que no vas a cambiar nunca (*) en la aplicación y que se va a estar lanzando cada x segundos en varios puestos, es mejor dejarla ya preparada y servida en el servidor e invocar a las vistas y/o procedimientos almacenados.

(*) No al menos hasta que venga un cambio en los requisitos, restricciones y/o en el rediseño o proceso de reingeniería para la aplicación.

Esto lleva también otra ventaja extra: hace más seguro nuestro al sistema y reduce también los peligros de una injección de código (a menos claro que el usuario tenga plena libertad de mandar a hacer lo que se le ocurra).

Yo al menos soy creyente de disponer vistas. Me resulta mucho más claro.

Saludos,

[Caminante]

Bueno lo que yo hago en esos casos es poner el codigo de busqueda en una funcion de clase (class function)

Código Delphi [-]
class function TfrmBusqueda.Buscar(DatoaBuscar:string;Var ID:integer):boolean;

En el parametro de salida retorno el codigo encontrado.
La llamada quedaria asi:

Código Delphi [-]
If TfrmBusqueda.Buscar(MIparametro,I) then
//Trabajar con el retorno (el parametro I)

Disculpa si no soy mas explicito pero es q de momento no tengo delphi a mano.

Espero te sirva

Saludos

[PepeLolo]

En mi caso todas las consultas para explotación de información las almaceno en la BBDD. Así no hay que generar nuevas versiones de la aplicación. Si es necesario un SP para a consulta, se crea y es transparente para el usuario, en pocos minutos o en muchos.... Depende de la complejidad, el usuario dispone de una consulta que hará uso de (SQL, SP o Vistas)