16 Y 32?

[leandro]

Amigos del foro tengan todos buen día.

El problema es el siguiente: hace un tiempo hice una aplicacion en 16 bits, esta aplicación funciona correctamente y con una velocidad extraordinaria.

Pero resulta que migre a 32 bits y la aplicacion se puso superlenta.

Hice las pruebas de los tiempos y los resultados fueron los siguientes:

16 bits -> 45 segundos
32 bits -> 150 segundos

En ese proceso no hay problema, pero hay procesos que son mucho mas largos y se vuelve muy molesto para el usuario estar esperando 20 minutos a que termine un proceso que se puede hacer en 5 minutos.

Alguien me puede ayudar. Alguna sugerencia, por que sucede esto?, no si tenga algo que ver con las bases de datos, los indices.? Help?

[leandro]

Bueno amigos... Les cuento que estuve haciendo varias pruebas y llegue a la conclusion que el problema de la velocidad son los filtros..

Ya que me muestra la base de datos sin filtro de una manera rapida pero al efectuar el un filtro en cuando se pone terriblemente lenta la aplicación.

Yo ejecuto los filtros de la siguiente manera:

Code: Select all  Expand view  RUN


SELE MYDBF
SET FILT TO CONTRO="04"
DBGOTOP()
DO WHILE !EOF()

    .......

   SKIP
ENDDO

Se debe hacer de otra manera el mysql, o existe alguna otra solicion para este problema?

[Antonio Linares]

Leandro,

Has probado a hacer una llamada a SysRefresh() desde ese do while ?

[jlaguilars]

Hola, usando índices CDX puedes aplicar SCOPES, o puedes hacer TAGS condicionados, ésto agiliza de una manera muy significativa el proceso, que hasta el pelo se te volará.

Todo lo anterior es mucho mejor que usar 'hard code' por ejemplo:

IF control = '04' <-----

Intentalo y verás.

Saludos

José Luis

[carlos vargas]

por experiencia que he tenido [x]harbor+fwh en manejos de tablas en mucho mas rapido en 32 bits que en 16 bits.


donde es mas rapido el 16 bits es en la salida de datos en aplicaciones modo consola. ahi [x]harbour solito es donde pierde.


efectivamente el caso de los filtro con los rdd nativos se manejan de una forma mas lenta. pero cuando se usa el rdd ads (en modo local) los filtros son mucho mas rapidos que en el rdd nativo.

una sugerencia es que utilices los scope para realizar filtros a las tablas, de esta forma la seleccion es muchismo mas rapida.

salu2
carlos vargas

[Manuel Valdenebro]

SELE MYDBF
SET FILT TO CONTRO="04"
DBGOTOP()
DO WHILE !EOF()

.......

SKIP
ENDDO

Leandro,

En este caso, yo creo que el filtro está fuera de lugar:

1) La base MyDbf debe tener un índice por el campo control
2) SELE MYDBF
SET INDEX TO control
IF DBSEEK ("O4")
WHILE mydbf->CONTROL = "04"
.......

DBSKIP()
ENDD
ELSE // opcional
ALERT ("PONES LO QUE QUIERAS")
ENDI

[leandro]

Amigos de foro muchas gracias por las respuestas...

Pero... y perdonen la ignorancia... la verdad nunca he usado los scopes ... alguien me puede regalar un ejemplillo. De antemano gracias.

[Manuel Valdenebro]

Amigos de foro muchas gracias por las respuestas...

Pero... y perdonen la ignorancia... la verdad nunca he usado los scopes ... alguien me puede regalar un ejemplillo. De antemano gracias.

Seguramente al escribir tu ultimo mensaje, no has leido el mio (lo hemos escrito practicamente al unísono).

¿Los indices que usas son ntx ó cdx?

[leandro]

Amigo uso indices CDX...

Gracias

[Raymundo Islas M.]

Leandro

Como te comentan los demas compañeros, debes tener la base indexada sobre los campos que vas a aplicar el scope, ya despues aplicas esto :

0 -> inicio del rango
1 -> final del rango

o a lo que es igual a decir desde-hasta


// Para Activar el scope
PAQSDET->( OrdScope( 0, Str( nPaq2Set, 4 ) ) )
PAQSDET->( OrdScope( 1, Str( nPaq2Set, 4 ) ) )
PAQSDET->( DbGoTop() )

// Para desactivarlo
PAQSDET->( OrdScope( 0, NIL ) )
PAQSDET->( OrdScope( 1, NIL ) )
PAQSDET->( DbGoTop() )


Es importante que al final lo desactives, si no, tu sistema va a "ver" solo los registros que apliquen al ultimo scope activado y sobre todo la llave del indexado debe ser identica al del scope.

Espero te sirva

Saludos