ADORDD. Set Filter. Muy lento.

[thefull]

Buenas

¿ Alguien a usado o valorado ADORDD de Antonio ?

He realizado una simple prueba con 600.000 registros en MySql
Tan simple como

USE CODPOST
set filter to hb_recno < 100
browse()

Para que el browse muestre rapidamente datos, pero el comportamiento es muy lento .
Encima si los registros estan mezclados , por ejemplo set filter to year( fecha ) > 2014 , es incluso muchos mas lento que Harbour, por lo que no se puede
usar en estas condiciones.

Estoy valorando el empezar a hacer pruebas intensivas, pero si esto tan simple funciona muy lento, no sirve, a no ser que exista alguna otra manera de hacerlo.
Hacer la select * from codpost where hb_recno < 100 , tarda 0.0048ms , asi que no es un problema del servidor, que encima es localhost

Saludoss

[thefull]

Buenas

Haciendo un poco de trampas, es posible simular un comportamiento mejor y es establecer la query antes de abrir la tabla;

Code: Select all  Expand view

    hb_adoSetQuery( "hb_recno < 100" )
   USE CODPOST NEW
 

Por lo que he visto siguiendo un poco el codigo , el problema esta en la funcion ADO_SKIPFILTER(), la eficiencia en esto,
creo que no es factible hacer un filtro;

Code: Select all  Expand view

DO WHILE ( ( aWAData[ WA_FILTERACTIVE ] <> NIL .AND. !Eval( aWAData[ WA_FILTERACTIVE ] ) ); // Nota: ¿ En serio evalua CADA registros !!??
         .OR. ( Set( _SET_DELETED ) .AND. lDeleted ) );
         .AND. ( ! aWAData[ WA_EOF ] .AND.  !aWAData[ WA_BOF ] )

         IF ! ( ADO_SKIPRAW( nWA, nToSkip, aWAData ) == HB_SUCCESS )  
            RETURN HB_FAILURE

         ENDIF
         ADO_DELETED(nWA,@lDeleted)

      ENDDO

En fin, a ver que tal va otras pruebas.

[AHF]

Rafa,

Google translator:

Primera meta de ADORDD es aplicaciones dbf portuarias a SQL como tey son.
SET FILTER es obligatorio para lograrlo.
Existen situación en la que los filtros no se pueden traducir a SQL declaraciones ex SET fFILTER TO MyFunc () por lo que deben trabajar como rdd dbf.

El ADO_SKIPFILTER funciona igual que skipfilter de tipo rdd dbf.
La cuestión aquí es que SET FILTER no se puede utilizar ni con RDD DBF o ADORDD con tanta tamaño de la tabla a menos con cierto SCOPE.

ADORDD funciona exactamente igual que un rdd dbf pero con el SQL con todas las limitaciones que rdd dbf tienen en este sentido ex SET FILTER.
Sin embargo el mayor tiempo cierta rutina toma con ADORDD será la más larga, ya sea con 1 o 300 usuarios o ya sea una lenta LAN o una WAN como sobre el tipo opuesto rdd DBF.

Si no puede utilizar el filtro se puede construir algo de consulta, pero no está obligado, como en dbf tipo rdd.

Con ADORDD puedes puerto de una aplicación que sea, entonces usted puede mejorar si usted desea usando statments SQL o una mezcla de ambos, pero usted continuará trabajando con las áreas de trabajo con todo referente datos para cada área encapsulada allí.

La mejor prueba que puede hacer es con el puerto alguna aplicación y ejecutar sin ningún cambio de código, además de algunos SETs.

Una cosa a su indudable SQL ou ADORDD (MS ADO) en One to One es siempre más lento que el tipo rdd dbf.

Yo estoy deseando que llegue aquí algunos resultados de los ensayos de usted.

Gracias

[thefull]

Gracias Antonio por la respuesta.

Sinceramente, en Clipper / Harbour, en sitios MUY concretos usamos filtros, por su excesiva lentitud, aunque en otros hice algunas mejoras , como los indices CUSTOMS, donde solucioné
muchos problemas de rendimiento, http://xthefull.blogspot.com.es/2014/02/harbouracelerando-al-viejo-set-filter-to.html , y otros usando SCOPES, pasamos de generar un
listado de 25 minutos, a 10 segundos!!

Se que el objetivo es trabajar con SQL sin tocar el código actual, muchas gracias por este trabajo fantástico que estás haciendo, pero mi meta es valorar en términos de rendimiento,
y empezar a introducir pequeños test sobre tablas reales traspasadas desde DBF a MySQL, con miles de registros.

Lo que tengo una duda, en el código fuente se advierta del uso de la función hb_adoSetQuery() , lo cual para este test, me ha ido de perlas, porque el browse() sobre 600.000 registros,
los cual son seleccionados 6319, a sido resuelto en 0.75 segundos!!

Con SET FILTER, NO ES USABLE, en este contexto, por lo tanto, hay que ir cambiando , al menos, pequeños trozos de código.

Veo en el codigo esto sobre la funcion hb_adoSetQuery()
"WE DONT USE GROUP BY BECAUSE RECORDSETS WITH THIS CALUSE DONT HAVE BOOKMARKS AND THUS NOT USABLE BY ADORD"

No entiendo muy bien a que se refiere, pero la pregunta es si hay algún tipo de problema de usarla.

[AHF]

Rafa,

Sinceramente, en Clipper / Harbour, en sitios MUY concretos usamos filtros, por su excesiva lentitud, aunque en otros hice algunas mejoras , como los indices CUSTOMS, donde solucioné
muchos problemas de rendimiento, http://xthefull.blogspot.com.es/2014/02 ... er-to.html , y otros usando SCOPES, pasamos de generar un
listado de 25 minutos, a 10 segundos!!

Yo uso mucho tiempo esta técnica, pero con arreglos porque trabajan con ADS sin recuerdo no era posible.
El registro se pasa a una matriz y se ejecuta en la matriz de registro.
Esta técnica es posible con ADORDD no ordkeyadd sé si es apoyada por ADORDD. Tienes que probar.

Se que el objetivo es trabajar con SQL sin tocar el código actual, muchas gracias por este trabajo fantástico que estás haciendo, pero mi meta es valorar en términos de rendimiento,
y empezar a introducir pequeños test sobre tablas reales traspasadas desde DBF a MySQL, con miles de registros.

Con adordd puede utilizar con las funciones normales de cualquier RDD o podas utilizar SQL solo o una mezcla de ambos.
Las tablas de cada área son siempre ctualizadas por ADORDD.
ex
use CTable
replace xfiled with xValue

o

hb_adoRddGetConnection (NWA): execute ("update....")
// Si no haces la resincronización al editar se mostrará este registro últmo la actualización.
En resumen, con ADORDD se puede trabajar directamente con SQL que será mucho más rápido, especialmente con filtros, etc.

Pieter Nobel está funcionando muy minucioso velocidad de la prueba entre las rutinas ADORDD y rutinas anuncios o rdd dbf.
Creo que va a publicar los resultados neste forum una vez concluido.

Lo que tengo una duda, en el código fuente se advierta del uso de la función hb_adoSetQuery() , lo cual para este test, me ha ido de perlas, porque el browse() sobre 600.000 registros,
los cual son seleccionados 6319, a sido resuelto en 0.75 segundos!!

Con SET FILTER, NO ES USABLE, en este contexto, por lo tanto, hay que ir cambiando , al menos, pequeños trozos de código.

puede utilizar la cláusula WHERE, pero los registros de consulta no trabajar como DBF RDD para que pueda hacerlo, pero hay que laterar código. EX

NREG: = RECNO () // esto asume que la inscripción está fuera del filtro
USO CTable
SET PARA FILTTER somevalue
GO TOP
GO NREG // esto fuera del filtro pero se puede acceder a él

NREG: = RECNO () // esto asume que la inscripción está fuera del filtro
USO CTable WHERE somevalue
GO TOP
GO NREG // no existe en la tabla

Veo en el codigo esto sobre la funcion hb_adoSetQuery()
"WE DONT USE GROUP BY BECAUSE RECORDSETS WITH THIS CALUSE DONT HAVE BOOKMARKS AND THUS NOT USABLE BY ADORD"

No entiendo muy bien a que se refiere, pero la pregunta es si hay algún tipo de problema de usarla.

Cuando controIa un conjunto de registros con GROUP BY o set no ofrece MARCADORES que son absolutamente indispensables para ADORDD.
Esto sucede con cualquier ADO CURSOR porque no hay correspondencia entre las filas agrupadas y filas de la tabla por lo que si usted abre una area con GROUP BY dan error.
En estos casos siempre se puede construir el conjunto de registros directamente a ADO pero no es capaz de asignar un área de trabajo.
También lo hace PIVOT.
Sin embargo esto ya no sucede si crearmos una tabla temporal para este resultado y aquí ahora pueden trabajar con la tabla temporal en un área de trabajo con ADORDD.

Resumiendo con ADORDD puede hacer todo lo que haces con qualuer rdd dbf y todo lo que usted hace con cualquier biblioteca de SQL o una mezcla de ambos.