Xailer & OZ Software

Hola!
Soy nuevo con Xailer, aunque vengo de 5win, así­ que no se me ha complicado mucho entenderle, con toda la ayuda que he encontrado en el foro y las estupendas notas de mi amigo y maestro René Flores ha sido un parto sin mucho dolor (hasta ahora), no sé como no migré antes, Xailer con Harbour es una verdadera maravilla.
Pero tengo el siguiente problema:
Al utilizar TDbfBrowse con una base ntx, en red compartida, el refresco es lentí­simo, de 6 a 20 segundos, al principio pensé que eran los í­ndices ntx, pero después de muchas pruebas decidí­ hacer una búsqueda incremental con :OnChar y haciendo DbSeek directamente en lugar de :seek.
Medí­ los tiempos, y el DbSeek es rapidí­simo, el tardado es el :Refresh(), pero por ejemplo en un :GoBottom(), el refresco es muy rápido.
Algo hace el refresh que no logro identificar.
Por el momento esta aplicación no la puedo migrar a CDX por que no tengo los fuentes.
Tabla DBF con 2 í­ndices NTX
100 mil registros
5 TDbfBrwColumns
Browse sin scrolls.
Aquí­ dejo el comparativo de tiempos con milisegundos (mS)
El DbSeek está postergado a 333 milisegundos después del útimo teclazo con un timer
En red, pero sin nadie más ocupando la tabla.
#1: Abriendo DirEmpr 10:38:33.3878 <- Abre la tabla con 2 í­ndices
#2: indices a 0 10:38:33.3908 <- OrdSetFocus a 0
#3: :SetDBF 10:38:33.3908 <- Le pongo le pongo alias al Browse
#4: antes de OrdSetFocus a: 2 10:38:33.3940 <- ahora sí­, activo el indice 2
#5: después de OrdSetFocus a: 2 10:38:33.3940 <- no tardó nada en activarlo
#6: DbSeek: 'v' 10:38:34.4984 <--Antes del DbSeek
#7: .T. 10:38:34.4994 <- tardó 10 mS en encotrarlo en el indice
#8: DbSeek: 'vi' 10:38:35.5134
#9: .T. 10:38:35.5144
#10: DbSeek: 'vit' 10:38:35.5246
#11: .T. 10:38:35.5256
#12: DbSeek: 'vita' 10:38:35.5448
#13: .T. 10:38:35.5448
#14: DbSeek: 'vital' 10:38:35.5510
#15: .T. 10:38:35.5510
#16: DbSeek: 'vitali' 10:38:35.5686
#17: .T. 10:38:35.5696
#18: DbSeek: 'vitalin' 10:38:35.5823
#19: .T. 10:38:35.5834
#20: DbSeek: 'vitalini' 10:38:35.5942 <- aquí­ pulsé la última tecla
#21: .T. 10:38:35.5943 <- encontró la palabra conpleta en 11 mS
#22: antes de :Refresh 10:38:36.6280 <- aquí­ se activa el Timer 338 ms después del último teclazo y llama al refresh()
#23: después de :Refresh 10:38:37.7405 <- Regresó del Refresh() tardó más de 1 segundo (1.1125mS)
#24: antes de :GoBottom() 10:38:40.0010 <- aquí­ mando un browse:GoBottom()
#25: después de :GoBottom() 10:38:40.0021 <- y sólo tardó 10 mS en ir al final y refrescar completamente el Browse
En red con otra persona ocupando la tabla
#1: Abriendo DirEmpr 10:39:29.9854
#2: indices a 0 10:39:29.9884
#3: :SetDBF 10:39:29.9884
#4: antes de OrdSetFocus a: 2 10:39:29.9930
#5: después de OrdSetFocus a: 2 10:39:29.9930
#6: DbSeek: 'v' 10:39:30.0685
#7: .T. 10:39:30.0705
#8: DbSeek: 'vi' 10:39:30.0865
#9: .T. 10:39:30.0875
#10: DbSeek: 'vit' 10:39:30.0959
#11: .T. 10:39:30.0969
#12: DbSeek: 'vita' 10:39:31.1160
#13: .T. 10:39:31.1171
#14: DbSeek: 'vital' 10:39:31.1258
#15: .T. 10:39:31.1258
#16: DbSeek: 'vitali' 10:39:31.1438
#17: .T. 10:39:31.1438
#18: DbSeek: 'vitalin' 10:39:31.1569
#19: .T. 10:39:31.1569
#20: DbSeek: 'vitalini' 10:39:31.1690 <- aquí­ pulsé la última tecla
#21: .T. 10:39:31.1700 <- los mismos 10mS en encontrar
#22: antes de :Refresh 10:39:32.2032 <- aquí­ se activa el Timer 342ms después del último teclazo y llama al refresh()
#23: después de :Refresh 10:39:44.4389 <- ¡Más de 12 segundos en hacer el refresh()!
#24: antes de :GoBottom() 10:39:45.5390 <- aquí­ mando un browse:GoBottom()
#25: después de :GoBottom() 10:39:45.5408 <- y sólo tardó ¡18mS! en ir al final y refrescar completamente el Browse
Ojalá me puedan ayudar, resolviendo esto, podré empezar a migrar la aplicación.
Ya intenté con Super:Refresh() para llamarlo de una clase superior y sigue igual.

Buenos dí­as,
Realmente no sé lo que está haciendo en su código. Necesitarí­a un ejemplo. No obstante acabo de revisar nuestro ejemplo datacontrolsDbfData2 y en mi opinión es instantáneo.
Observe que el objeto TDbfBrowse tiene un mecanismo propio para hacer búsquedas autoincrementales que es muy fácil de usar:
WITH OBJECT ::oEdiBusqueda := TEditBtn():New( ::oRebar1 )
:oBitmap := "lupa16"
:OnBtnClick := {|o| ::oBrw:Seek( o:Value ), nil } <<<<<<
:nMaxLength := 100
:Create()
::oBrw:oSeek := ::oEdiBusqueda <<<<<<<<<<<<<
END
Y atrape el evento OnSeek del browse:
METHOD BrwSeek( oSender, cSeek ) CLASS TForm1
RETURN ::oDataSet:Seek( Upper( cSeek ) )
Saludos

Gracias por contestar.
Sí­, ya intenté usarlo como los ejemplos, es más, con el mismo Editor de tablas DBF del propio Xailer, también se tardar muchí­simo, en abrir el indice, en buscar y en darle Skip.
Hice pruebas de todo tipo, con CDX funciona rápido el refresh(), pero no con NTX.
Aclaro, no es la búsqueda DBF la tardada, la hago con DBSeek, sólo tarda de 10 a 11 milisegundos, el tardado es TDbfBrowse:refresh(). ya también intenté el refresh con un ::Super:Super:refresh() y lo mismo.
Reindexé con la utilerí­a de Xailer y sigue igual.
ímbito:
Local: es rapidí­simo
En red sin nadie más: Muy rápido, como dices instantaneo.
En red con más de una persona utilizando el mismo DBF es cuando se alenta de 6 a 20 segundos.
Browse: TDbfBrowse
Columnas: 6
Sin Scrolls, ni vertical ni horizontal
ni TBrwRecSel
DBF: 100 mil registros
Indices: NTX
campos indexados y descripción de sus campos.
í­ndice 1: ClaveEmpre N, 6,0
í­ndice 2: Empresa C, 80,0
A continuación pego el código que utilicé para generar el la pantalla del Debug del post anterior.
//Aquí­ capturo el teclazo con :OnChar, reinicio el timer y hago la búsqueda
::oTimerSeek:Enable()
OutDebug("DbSeek: '"+cSeek+"'" + str_time() )
if (::cAliasEmpr)->( DBSeek( Upper( cSeek ), .t. ) )
OutDebug(".T."+ str_time() )
::cSeek:=cSeek
::oBuscar:Value:=cSeek
else
OutDebug(".F."+ str_time() )
MsgBeep()
endif
//Cuando termina el timer (333mS) se ejecuta este método.
METHOD TimeSeek( oSender ) CLASS tBuscarEmpresa
::oTimerSeek:Disable()
OutDebug("antes de :Refresh" + str_time() )
::oBrwEmpr:Refresh( .F. )
OutDebug("después de :Refresh" + str_time() )
RETURN Nil
FUNCTION str_time()
RETURN " "+Time()+"."+ Right(ToString( hb_MilliSeconds() ) ,4 )

Buenos dí­as,
Entonces no es un problema de Xailer. El problema que comenta se produce básicamente porque a partir de Windows Vista el sistema de bloqueos que utilizan los DBFs está penalizado con la configuración de 'cacheo' de ficheros que utilizan las últimas versiones de Windows. Y es un problema inherente al sistema de bloqueos y por lo tanto de Harbour, por lo que entiendo que deberí­a ser exactamente igual que usase Xailer u otro producto.
Existen una serie de valores de configuración del registro que permiten mejorar la velocidad, pero personalmente lo desaconsejo pues al beneficiar a estos procesos perjudicará al resto. Y además dudo bastante que sirvan de algo.
Mi recomendación:
- Utilice ADS si quiere seguir con ficheros DBF
- Intente alojar los archivos en un servidor Linux con Samba (el tí­pico NAS). He oí­do que mejora bastante pero no lo he probado personalmente.
- Pásese a SQL.
Un saludo

El servidor es Linux, centos 5.6
Y por el momento no puedo cambiar de NTX, ya que no tengo los fuentes de la aplicación crí­tica de la empresa.
Lo mismo pasa si utilizo la aplicación en Windows XP
Pero insisto, el problema no es el DBseek, la lentitud está en el refresh(), en el ejemplo que mandé están los tiempos
La búsqueda no tarda nada:
#20: DbSeek: 'vitalini' 10:39:31.1690 <- aquí­ inica el DBSeek
#21: .T. 10:39:31.1700 <-sólo tarda 10 milisegundos en encontrarlo
El refresh() es el que se tarda
#22: antes de :Refresh 10:39:32.2032
#23: después de :Refresh 10:39:44.4389 <- ¡Más de 12 Segundos en hacer el refresh()!
Pero con un Browse:GoBottom() es instantáneo el refresh
#24: antes de :GoBottom() 10:39:45.5390
#25: después de :GoBottom() 10:39:45.5408 <- y sólo tardó ¡18 milisegundos! en ir al final y refrescar completamente el Browse
Al auditar el uso de Red, hace mucha lectura de datos por todo ese tiempo que se tarda en refrescar, como si leyera muchos registros, antes de repintar.

Hola buen dia. Yo estoy haciendo casi lo mismo que tu. accesando a unas dbf de cliper 53 usando archivos ntx. y no veo ninguna lentitud de la que comentas. todos los equipos estan con windows xp. La unica lentitud que observo es al momento de abrir los ntx. en lo demas lo considero "normal"
Aqui un ejemplo

WaitOn("Abriendo archivos..")
::oNtxDataSource:cConnect:= "Servidor01sia"
WITH OBJECT ::oDbfLibros
:oDataSource:= ::oNtxDataSource
:cName := "SIACLIBR.DBF"
:aIdxFiles := { "SIACLIBR.NTX","SIACLIB2.NTX", "SIACLIB3.NTX", "SIACLIB4.NTX", "SIACLIB5.NTX" }
:lOpen := .T.
END WITH
WAITOFF()
::oDbfLibros:OrdSetFocus(5)
::oDbfLibros:GoTop()

Saludos

Muchas gracias ya está resuelto, tuve que agregar un método llamado SemiRefresh sin nada de información adicional, ya que no manejo indices CDX ni Scroll Vertical
Aquí­ están los tiempos
#21: DbSeek: 'vitalini' 12:56:50.0882
#22: .T. 12:56:50.0884
#23: antes de :SemiRefresh 12:56:51.1223
#24: después de :SemiRefresh 12:56:51.1225
CLASS TBrowse FROM XBrowse
PUBLISHED:
METHOD SemiRefresh()
ENDCLASS
METHOD SemiRefresh( lComplete ) CLASS TBrowse
::nKeyNo := 1
::nRowSel := 1
::Super:Super:Refresh( .F. )
return nil

Por lo que comentas posiblemente la demora se produca en el uso de las funciones de Harbour OrdKeyGoto() y OrdKeyCount(). Te sugiero que hagas lo siguiente para probarlo:
oBrw:OnKeyNo := {|oBrw, nPos| ;
iif( nPos != NIL, oBrw:Goto( nPos ), oBrw:Recno() ) }
oBrw:OrdKeyCount := {|oBrw| oBrw:RecCount() }
Si es así­ es muy probable que ambas funciones no estén muy optimizadas para NTX en Harbour. Lo cual tiene mucho sentido ya que dichas funciones aparecieron por primera vez con el RDD de Comix creo recordar que era CDX.
Saludos

Ok, voy ha probarlo con un TDbBrowse
Gracias!!

El dódigo que me mandaste lo dejé así­, no estoy seguro se es correcto.
::oDBBrowse1:OnKeyNo := {|oBrw, nPos| iif( nPos != NIL, oBrw:Goto( nPos ), ::oDbfDataSet1:Recno() ) }
::oDBBrowse1:OnKeyCount := {|oBrw| ::oDbfDataSet1:RecCount() }

Y la búsqueda incremental nativa funciona rapí­dí­sima con las mismas tablas en Red, pero el goBottom (tecla fin) es tardado, pero el GoTop es rápido.
Gracias por tu interés.

Es correcto. Sus pruebas me demuestran claramente que lo que se ralentiza es el manejo de í­ndices NTX en entornos de red. Y es un problema de Harbour. Si sólo sus aplicaciones acceden a los datos puede intentar cambiar el esquema de bloqueos:

Los eventos sobrecargados que le he dado no deberí­a usarlos en sus programas por dos motivos:
- OrdKeyNo() indica la posición relativa del recno() actual según el í­ndice usado. Al usar Recno() en vez de OrdKeyNo() el ascensor de la barra de scroll vertical no se mostrará correctamente.
- OrdKeyCount() tiene en cuenta los filtros. RecCount() no.
Saludos


Attached files

No son las únicas, hay otras aplicaciones que lo utilizan, y otras que voy a amigrar a Xailer.
Por lo pronto, voy a dejarlo así­ con el SemiRefresh(), ya que no necesito utilizar Scroll Vertical.
Gracias por tu apoyo.