TXBROWSE ¿Cómo acelerarlo en mi caso?

[ander7319]

Harbour 3
FWH 13.1
Borland 582

Estoy intentando modificar el codigo para pasar de TWBROWSE a TXBROWSE y en este caso también de 16 a 32 bits:
Tengo un Browse con dos bases de datos (DBF) relacionadas (SET RELATION) y además filtradas (SET FILTER) ya que sólo debe mostrar el browse los registros que cumplen cierta condición en varias de las columnas.
Ambas bases de datos pueden ser modificadas por separado, por otros usuarios, y con otros programas; pero obviamente usando los mismos índices.

En resumen:
1 Base de datos.
-Codigo
-Denominación
2 Base de datos.
-Codigo
-Fecha
-Importe

Ambas relacionadas por "codigo". Sólo debe mostrar el browse los registros de la primera base de datos entre una cota de fechas y con "importe" <> 0 de la segunda base de datos. Se muestran en el browse los cuatro campos. Además debe poderse ver ordenados por "código" o "denominación" del indice de la primera base de datos

Me funciona, pero no es que va lento, las plantas crecen más rápido.

¿A alguien se le ocurre alguna idea para acelerar el xbrowse hasta llegar a conseguir que al menos sea operativo?

En 16 bits y con TWBROWSE tardaba un poco en hacer la relación y el filtrado, después era perfectamente operativo. Ahora, con practicamente el mismo código no lo es.

Muchas gracias de atemano y un saludo

[joseluisysturiz]

Ander, creo que no debes hacer muchos cambios, lo que si te recomendaria es que si estas trabajando con indices .NTX te cambies de una vez por .CDX, ya con eso aumenta tu velocidad y seguridad en tus datos. El manejo de la clase TDATABASE es buenisima para DBF, del resto todo funciona bien, no me gusta mucho set filter, pero bueno, cualquier cosa estamos a la orden, saludos...

[ander7319]

Mchas gracias por la rápidísima respuesta:

Ya se usan indices CDX, en ambas bases de datos. También soy consciente de que el SET FILTER está relentizandolo todo... pero no se ocurre otra forma de producir el filtrado en el xbrowse sin ella, habida cuenta de usar ordscope() en este caso... se me antoja complicado. En otros browses del programa, el filtrado lo hago mediante este ordscope() y todo funciona fenamenal. En este caso con la relación, la ordenación, y el filtro .... se me está cruzando... pero cruzando. No encuentro una solución real y práctica.

Un Saludo y gracias. Voy a seguir intentandolo a ver si encuentro una forma de hacerlo operativo.

[joseluisysturiz]

Has probado con DBSETFILTER().? creo que deberias probar con otra opcion, yo en mi caso prefiero con DBF hacer mi filtro de forma manual, creo una DBF TMP o un ARRAY con los campos que cumplan la condicion, asi se que de verdad me muestra la cantidad de registros que quiero y no que solo me oculta los que no quiero o que no cumplen la condicion dad, nose si sera mejor o peor como lo hago, pero siento que me va muy bien, ademas de recudir el tamaño de la DBF a mostrar en el xBrowse que tambien es rapido, bueno seria ir cambiandote a MYSQL, alli olvidas todos esos problemas de velocidad, estamos a la orden, saludos...

[ander7319]

Tomo nota: estudiar cambio a Mysql. ¿Sabes de algún "buen" manual?

La solución del temporal o el array, ya la he considerado, pero pierdo la situación on-line actual. Cualquier modificación que se produzca en los ficheros originales (que se actualizan constantemente) no sería visible hasta una nueva creación del temporal. Sí es algo más rápido, pero no es una opción en este caso.

[joseluisysturiz]

Para manual, millones en Mr:google, te doy link del mismo de la web de mysql, luego de esto hay muchos ejemplos aca en el foro, y tienes 2 clases super buenas, tdolphin que yo uso de Daniel y tmysql creo de willian, saludos...

MySql
http://dev.mysql.com/doc/refman/5.0/es/index.html

tdolphin
viewtopic.php?f=6&t=19204&hilit=tdolphin
http://tdolphin.blogspot.com/2010/11/co ... d-lib.html

tmysql
viewtopic.php?f=6&t=25458&p=138734&hilit=tmysql#p138734

[carlos vargas]

Lo mas probable es que estes usando el rdd DBFCDX el cual no tiene bitmap filter, esto bitmap filter aceleran enormemente los filtros, ya que usa los indices para encontrar los registros a incluir en el filtro. (esto en Foxpro por ejemplo se llama tecnologia Rushmore, en ads es AOF)

si usas el rdd ADS podras hacer uso de esta tecnologia.

basicamente funciona de la siguiente manera.

si usas un filtro como este

select "prestamos"
set filter to fecha_pago >= date()

donde fecha_pago es un campo en la tabla a filtrar, este campo debe estar indexado, esto provocara que el filtro use el indice para encontrar mas rapidamente el registro.
y el rdd gestione mas rapidamente la inclusion del registro en el filtro, es cierto que esto es facilmente reemplazable en el rdd DBFCDX con un scope, ya que igualmente fecha_pago debe estar indexado, y hacemos un scope SetScope( date(), NIL ), aca abos tendra una velocidad similar.

pero, siempre un pero, si el filtro sube en complejidad, por ejemplo

set filter to ( fecha_pago >= date() .or. cliente_mp=.t. ) and saldo >0

ya la cosa se complica para un scope, (tu bien lo sabras, ya que esto es lo que probablemente te quito las ganas de usar scope)
si bien no es complicado usar aca un scope, genera un poco mas de trabajo, campos extras, suma de expresiones, conversiones, etc.

ahi es donde los filtros en ads local superan a un scope en dbfcdx, por que en ads solamente seria necesario crear indices a los tres campos involucrados y tachan el filtro volaran, como los Blackbird que pasaban por el cielo cuando era niño aca en nicaragua .

si previamente indexamos los tres campos involucrados en el filtro:

index on fecha_pago tag fecha_pago
index on cliente_mp tag cliente_mp
index on saldo tag saldo

no seria necesario nada mas que tener indexado estos tres campos para que ADS use su tecnologia AOF (Advantage Optimized Filter ) para acelerar los filtros a velocidades similares a un scope.

si los tres campos estan indexados tendremos un AOF con nivel ADS_OPTIMIZED_FULL (velocidad de un ferrari)
si dos de los campos estan indexados tendremos una AOF con nivel ADS_OPTIMIZED_PART (velocidad de toyota)
y si ninguno de los tres campos esta indexado entonces tendremos una AOF con nivel ADS_OPTIMIZED_NONE el cual se comportara como tu filtro actual el cual es lento, muy lento, como el caballo del malo al final de las peliculas de vaqueros cuando los siguen los buenos.

salu2
carlos vargas

[ander7319]

Muchas gracias,
Tomo nota y voy a probar. Son bastantes cambios, pero parece que puede merecer la pena.

Un saludo.

[elvira]

Un par de dudas Carlos:

En la creación del índice, ¿el tag debe ser obligatoriamente igual al nombre del campo para que funcione el AOF?.

¿Funciona el AOF con índices temporales TO TEMP TEMPORARY?.

Mil gracias.

[carlos vargas]

TO TEMP TEMPORARY ( me parece que esto no esta implementeado en ADS solo en los Rdd Nativos de harbour.

[elvira]

Carlos,

En la creación del índice, ¿el tag debe ser obligatoriamente igual al nombre del campo para que funcione el AOF?.

Gracias.

[carlos vargas]

nop.

salu2

[nnicanor]

Lo puedes solucionar facil sin hacer filtro , en una de las columnas haces el seek a la otra relacionada y creas inices condicionado donde imorte sea diferente cero y punto

PROD->( DBSEEK( IMEX->CODPRO ) , NOMPRO )

Slds

[praul]

Con indices NTX y aplicacion compilada con XHARBOUR trabaja muy bien llos filtros con ORDERSCOPE()

OrdScope(0, cClave )
OrdScope(1, cClave )

[joseluisysturiz]

Muchas gracias,
Tomo nota y voy a probar. Son bastantes cambios, pero parece que puede merecer la pena.

Un saludo.

Este es mi correo y skype joseluisy@hotmail.com / joseluisy alli podemos estar en contacto haber si resolvemos y para pasarte las cosas que tengo de MYSQL, saludos...