FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
paso de parametros a tdataset
Hola, frecuentemente utilizo una rutina como esta para "enlazar" un dataset con otro
pues bien, estoy intentando crear un procedure generico que reciba 2 parametros uno el dataset y el otro el campo:
el problema es que el dta set no me acepta el paramByName e intentado con :
pero no resulta... espero que se entienda la idea Gracias |
#2
|
||||
|
||||
No puedes pasar el nombre de un campo como parámetro.
Además, creo recordar que está mal el planteamiento que haces aquí: Creo recordar que, en todo caso, aunque no es necesario el prepare, debes hacer así:
|
#3
|
||||
|
||||
La idea del "prepare", es que se cree el SQL con parámetros (como ya lo haces), y se compila una sola vez la instrucción (prepare), se da valor a los parámetros y se ejecuta/abre.
Tiene sentido cuando un mismo SQL se va a ejecutar varias veces en la misma tabla con los mismos campos, por ejemplo inserciones masivas, actualizaciones, selecciones, etc...
Muy típico en listados por fechas, creas la ventana de listados donde asignas el SQL, lo preparas y cuando el usuario cambia las fechas en la interfaz, solo asignas el valor de los parámetros. En teoría es lo más eficiente, ya que evitas: - averiguar los campos que se seleccionan (solo se hace una vez en la vida del Form, donde se crean los campos del TQuery, rellenando el FieldsDef, etc). - compilar el SQL para obtener el plan de ejecución (qué índices se usarán según los join que hagas, los campos del order by, etc) Es cierto que no es necesario llamar a "prepare" porque lo hace internamente, pero es buena práctica; solo con ver un "if not query.prepared", sabes que el SQL no se modifica. Obviamente no tiene sentido hacerlo en un FormCreate, porque si se acaba de crear el Form y el TQuery, aún no está preparado. Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#4
|
|||
|
|||
Hola, creo que si se puede de hecho lo estoy haciendo en este momento, claro con algo mas en el código:
tengo 2 tquery personas:
autos:
y luego para llamar al procedure pues :
a lo que me refiero es que le puedo pasar el nombre y el valor de un parametro al paramByName ya que lo que espera es un String .... claro que es lo que falta pues como decir con un parametro cual es la query en cuestion, lo intente con
mi idea es hacer algo asi
, pero no funciona y alli esta el detalle ....lo que quiero es hacer ese casting y eliminar muchas declaraciones de este procedure para cada query en particular y asi reduciria mucho el codigo ... Saludos ... |
#5
|
||||
|
||||
Muy complicado de hacer; las diferentes implementaciones estan en distintos arboles de herencia.
Por ejemplo en DB.pas se define el tipo TParam para operar con los parametros de los TQuery Pero en ADODB.pas se define otro tipo TParameter que no tiene nada que ver con TParam Tampco hay un ancestro comun para los TQuery. ADOQuery hereda de TCustomAdoDataSet quien hereda de TDataSet; y es en TCustomAdoDataSet donde se agrega la funcionalidad para los TParameter Lo mas cercano que podes hacer es declarar una interface y luego crear clases wrapper, asi:
Wrapper ADO:
Ejemplo de uso:
|
#6
|
||||
|
||||
Es cierto lo que comentan, dependiendo del dataset, hay diferentes formas de definir los parámetros de un dataset.
Dataset.ParamByName() .. ó DataSet.Parameters.ParamByName()... Tendrás que hacer unas pruebas, y ver si utilizas una forma u otra teniendo en cuenta qué objetos utilizas. Si utilizas diferentes objetos, tendrás que hacer un cast. Espero haberte dado alguna idea. Un saludo
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
#7
|
||||
|
||||
No es buena idea, ya que si cambias la clase del dataset, te tenes que acordar de agregar el cast a esa clase; es agregar un if
Ademas, si se manda por parametro un TDataSet, eso quiere decir que puedo mandar sin problemas un TTable, un TClientDataSet; y evidentemente eso no es lo que espera el procedimiento Tambien implica agregar en la clausula uses las distintas bibliotecas: ADODB para TADOxx, DB para TDataSet, DBClient para TClientDataSet; esto es malo porque es acoplamiento (se depende de otra unidad para poder compilar la nuestra). El codigo acoplado es mas dificil de mantener, mas dificil de testear, mas dificil de aislar. Yo siempre estoy luchando con sacar todo lo que sobra en los uses, y si puedo poner todo en la seccion de implementation, mejor aun Delphi por suerte soporta OOP e interfaces, no volvamos a la programacion estructurada Lo mas sano es declarar una interface y enviarla como parametro; si mas adelante cambio de TADOQuery a TQuery, al enviarlo por parametro el compilador me va a recordar amablemente que la clase TQuery no implementa dicha interface Hay que aprender a escribir codigo que arroje los errores en tiempo de compilacion, no en ejecucion Última edición por AgustinOrtu fecha: 01-02-2016 a las 14:30:10. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Copiar informacion de un Tdataset a otro Tdataset | joelphi | Varios | 10 | 19-02-2009 22:27:44 |
Paso de parámetros a TDataset | arturom | Firebird e Interbase | 9 | 04-04-2008 18:04:03 |
Paso de parametros | senpiterno | Varios | 1 | 11-04-2004 03:44:17 |
paso de parametros | gustavo2 | SQL | 7 | 16-01-2004 15:46:23 |
Paso de parametros | __cadetill | PHP | 2 | 12-08-2003 10:15:09 |
|