Velocidad con xbrowse

[informaticaeloy]

Hola. Hace un tiempo que pregunté en el foro sobre la velocidad de ejecución de mi aplicación, ya que trabajo con bases de datos dbf e índices ntx. Cambié de listbox a xbrowse y con la tabla de artículos que trabajo que tiene 150.000 registros, al hacer búsquedas en red tarda unos 3 minutos en encontrar el dato buscado. Me disteis varias ideas que he ido probando pero la velocidad sigue igual de lenta. Por favor, ando perdido y ya mi cliente está un poco mosqueado. Si alguien puede, le podría mandar el prg y el dbf para que lo probara, ya que a mi se me han acabado las ideas y no veo factible tener que volver a listbox.

Por favor, una ayudita. Gracias.

[pablovidal]

Hace mas de 10 años que no uso Dbfs, pero pasate a indices CDX son mas estables y rapidos

[cnavarro]

Y la velocidad en modo local, es la misma?

[informaticaeloy]

Hola. Si, en local la velocidad es casi instantánea.

[cnavarro]

Que sistemas operativos estan implicados? Servidor y cliente(s)

[informaticaeloy]

Hola. Yo mis pruebas las hago con servidor xp y cliente xp y 7. En el domicilio del cliente server y clientes son xp. Lo tengo configurado con grupo de trabajo, carpeta compartida y acceso a unidad de red. La red es cableada en base 100. Con listbox no problem, pero con xbrowse, .............. Cierta partes del programa aún no las he actualuizado a xbrowse y funcionan igual de rápido en local y en red.

[acuellar]

Como indica Pablo, debes cambiar a CDX.

Puede ser que estes usando FILTER el cual hace lento la búsqueda. Si es así es aconsejable usar SCOPE.

Saludos,

Adhemar

[hmpaquito]

Pues si, los .cdx son mas eficientes segun su creador:

On Sat, 04 Apr 2015, Sergy wrote:

Hi Sergy,

> Thank you for explanation.
> Can you say - CDX index is much effecient than NTX ?

It depends. Usually yes for two reasons:
1. much smaller indexes what is significant when index
files are accessed by network or they are two big to
be cached by system in local access.
2. In NTX format record number is not part of index key.
It means that after GOTO or when record is modified
NTX RDD finds first key with value calculated for current
record and then makes linear index scan checking all keys
with the same value until it finds key with record correct
number. If table has a lot of non unique keys then such
operations are much slower then pure binary search like in
CDX and NSX (in both formats record number is hidden part
of index key during sorting). In [x]Harbour I added RDDI
actions which change default NTX behavior to the same as
in NSX and CDX:
rddInfo( RDDI_SORTRECNO, .t., "DBFNTX" )
for more information look for
2005-08-02 00:10 UTC+0200 Przemyslaw Czerpak
in oldlogs/ChangeLog.023 in xHarbour SVN repository.

> I know - it is "compressed", so gives a smaller CDX file.
> But does CDX data occupy less size in RAM than NTX ?

It's unimportant. CDX needs more memory just simply to
decompress keys from leaf pages which may contain much
more keys then in NTX. But is it a problem for you if for
each index file RDD allocates additional ~10 KB of RAM?
The CPU cost of index updating is usually noticeable bigger
in CDX then in NTX anyhow NTX needs much more IO operations
due to bigger size of index files and IO operations usually
need much more time.

best regards,
Przemek

https://groups.google.com/forum/?fromgr ... B-eDbnEDMA