Club Builder - Foros de discusión Club Builder
Foro de C++Builder en español
 
 FAQFAQ   BuscarBuscar   MiembrosMiembros   Grupos de UsuariosGrupos de Usuarios   RegistrarseRegistrarse 
 PerfilPerfil   Entra para ver tus mensajes privadosEntra para ver tus mensajes privados   EntrarEntrar 

Datos vivos, datos muertos... ya no vivo, yo me muero :P

 
Publicar nuevo tema   Responder al tema    Foros de discusión -> Bases de Datos
Ver tema anterior :: Ver tema siguiente  
Autor Mensaje
Mensaje    Asunto: Datos vivos, datos muertos... ya no vivo, yo me muero :P Responder citando

Más alla del chiste del asunto, estoy preocupado por una caracteristica (sin terminar supongo) de los componentes Zeos.

Paso a explicar. Estoy desarrollando una aplicacion que utiliza una base de datos sqlite. Me conecto con un TZConnection y trabajo directamente con los datos vivos con un componente TZQuery. De ahi su facilidad de uso.
Pero parece ser que las propiedades/metodos Filter y Filtered de TZQuery no han sido bien implementadas, ya que el resultado, sea cual sea el filtro es el conjunto nulo de datos.
Sé que muchos estarán pensando: porque no usas TClientDataSet conectado al conjunto de datos vivos??...
Pues por una sencilla razon: no tendria porque usarlos, utilizo una base de datos que va a trabajar monopuesto y monousuario, que sentido tendria tener una copia de los datos en memoria?, segun mi punto de vista no tendria sentido.
Entonces me encuentro en esta disjuntiva, que proceder me recomiendan?
_________________
Gracias!

Visita http://www.clubdesarrolladores.com
Volver arriba
Ver perfil de usuario Enviar mensaje privado Visitar sitio web del autor
Mensaje    Asunto: Responder citando

Sencillamente DataSet's, por que por lo que acabas de comentar este es otro de los tropiezos que traemos desde gestores como Acces o Dbase (Clipper, FiveWin, Fox),

cuando trabajas con sentencias SQL que es tu caso, efectivamente traes la informacion a la maquina, pero depende de la manera en que estas trayendo la informacion


ejemplo mal echo a proposito

1.- dentro del form usa el componente que mas prefieras para conectarte a la base de datos.
2.- conecta el DataSource

3.- botones primero, adelante, anterior, ultimo (funcionan igual con el DBGrid), agregar, buscar eliminar, editar

1.- problema como cargas la base de datos?
select * from tu tabla ?
TuComponete->Open() ?

bien siempre cargaras la tabla COMPLETA en memoria asi este en un solo registro

forma 2 mas eficiente

1.- dentro del form usa el componente que mas prefieras para conectarte a la base de datos.
2.- conecta el DataSource

3.- agregar, buscar eliminar, editar <- solo estos cuatro? efectivamente solo estos cuatro.

usa una sentecia como la siguiente
Select * from tutabla Where codigo = :codigo

TuComponete->Filtered = true y etc etc,

como anterior dices el componente no trabaja correctamente con lo
anterior del Filtered, es por que no soporta lo que estas haciendo. al final
que es lo que haces,
dentro del componente que tiene los registros estas haciendo una seleccion pero de 1 a 1, es decir empiezas en el primer registro comparando la condicion del Filtered si la cumple lo filtras
es correcto? si y no a la vez, puesto que primero tienes que cargar TOOODOOOS los registros para aplicar este filtro y eso es cargar toda la tabla en memoria y eso es lo que no quieres.

Bien sin mas comentarios usa un TDataSet que soporte sentecias SQL y con eso tienes solucionado el problema ahora esta en mono usuario, mucho mejor, pues el usuario no tiene que navegar por ningun cable de red, para traer los datos. asi que que el tiempo de respuesta es relativamente corto

saludos...





dentro de un form usas 1 DBgrid de manera clasica
_________________
Cool
Volver arriba
Ver perfil de usuario Enviar mensaje privado Enviar email MSN Messenger
Mensaje    Asunto: Responder citando

Resumiendo, me recomendas que use parámetros en la consulta o a lo sumo la cree de la forma:

'Select * from tabla1 where upper(campo) like ' + QuotedStr("%"+ AnsiUpperCase(edtBuscar->Text)+"%")

De esa forma estaria trayendo solo lo necesario, verdad?

Bueno, hay un detalle que no mencioné. Las busquedas se realizan en un evento OnChange de un Edit (edtBuscar), por lo que abrir y cerrar la conección tantas veces simplemente no me parece lo mejor.

Mi idea es trabajarlos en una especie de caché, pero sin llegar a tener copia de los datos en la memoria de otro componente (ClientDataSet). Por eso tenia la esperanza que mi dataset (el que ejecuta la consulta), me permita realizar el filtro con esa unica copia de datos traidos, pero son sobrecargar de lecturas la pequeña base de datos.

La gran pregunta:

Cuando a mi TZQuery, le ejecuto Next, le pide los datos uno a uno a la base de datos o simplemente trabaja con una copia interna (una suerte de clientdataset) de los mismos?

Creo que esa es mi gran interrogante.

PD: Gracias por contestar tan rapido.
_________________
Gracias!

Visita http://www.clubdesarrolladores.com
Volver arriba
Ver perfil de usuario Enviar mensaje privado Visitar sitio web del autor
Mensaje    Asunto: Responder citando

CID@Devs escribió:
Resumiendo, me recomendas que use parámetros en la consulta o a lo sumo la cree de la forma:

'Select * from tabla1 where upper(campo) like ' + QuotedStr("%"+ AnsiUpperCase(edtBuscar->Text)+"%")

De esa forma estaria trayendo solo lo necesario, verdad?


R: efectivamente eso es lo que se desea

CID@Devs escribió:

Bueno, hay un detalle que no mencioné. Las busquedas se realizan en un evento OnChange de un Edit (edtBuscar), por lo que abrir y cerrar la conección tantas veces simplemente no me parece lo mejor.

Mi idea es trabajarlos en una especie de caché, pero sin llegar a tener copia de los datos en la memoria de otro componente (ClientDataSet). Por eso tenia la esperanza que mi dataset (el que ejecuta la consulta), me permita realizar el filtro con esa unica copia de datos traidos, pero son sobrecargar de lecturas la pequeña base de datos.


R: usa una relacion Maestro detalle , asi cuando cambie en el maestro - cambiara en el detalle sin necesidad de abrir y cerrar tablas..
aqui en el foro he dejado algunos ejemplos... pero no recuerdo los enlaces Embarassed je je

CID@Devs escribió:

La gran pregunta:

Cuando a mi TZQuery, le ejecuto Next, le pide los datos uno a uno a la base de datos o simplemente trabaja con una copia interna (una suerte de clientdataset) de los mismos?

Creo que esa es mi gran interrogante.

PD: Gracias por contestar tan rapido.


R: si lo tiene reflejado en memoria como un DBGrid, no, pero si es un form con DBEdits y lo mueves por un boton, si lo lee nuevamente desde la base de datos...

saludos...
_________________
Cool
Volver arriba
Ver perfil de usuario Enviar mensaje privado Enviar email MSN Messenger
Mensaje    Asunto: Responder citando

Mirá, tiene cursor bidireccional por lo que puedo usar el dataset directamente en un dbgrid.
En cuanto a lo de maestro/detalle no se si se le podria aplicar a ésto. Pero ya me las arreglare.
Gracias por clarificarme algunas ideas.

Saludos!
_________________
Gracias!

Visita http://www.clubdesarrolladores.com
Volver arriba
Ver perfil de usuario Enviar mensaje privado Visitar sitio web del autor
Mensaje    Asunto: Responder citando

Me apresuré al decir que el componente TZQuery tenia el método Filter mal implementado... en realidad estaba implementado de otra manera. Y me enteré de eso luego de optar por trabajar con una copia en memoria :S
En fin, la solución es tan simple que da risa y bronca a la vez.
Poner:

Código:
Filter = "upper(" + campo + ") like " + QuotedStr("%"+ AnsiUpperCase(edtBuscar->Text)+ "%")

Estaria mal porque el componente usa * en lugar de % y ? en lugar de _
La solución:

Código:
Filter = "upper(" + campo + ") like " + QuotedStr("*"+ AnsiUpperCase(edtBuscar->Text)+ "*")


Y pensar que perdi dias con esto...

Solo queria compartirlo, Saludos!.
_________________
Gracias!

Visita http://www.clubdesarrolladores.com
Volver arriba
Ver perfil de usuario Enviar mensaje privado Visitar sitio web del autor
Mostrar mensajes de anteriores:   
Cambiar a:  
No puedes publicar temas nuevos en este foro
No puedes responder a temas en este foro
No puedes editar tus mensajes en este foro
No puedes borrar tus mensajes en este foro
No puedes votar en las encuestas de este foro


Hosting WordPress Indedmedia desde 3,99 €
© 2002–2026 Club Builder · Funciona con phpBB.