lentitud tremenda en red

[joseluispalma]

Buenas tardes:

Ejecutamos el programa desde una carpeta compartida del servidor, por ejemplo \\servidor\app\app.exe.

Cuando sólo lo está ejecutando una estación de trabajo, todo funciona perfecto, pero cuando se conecta un segundo pc, las operaciones del RDDdbfcdx y los xbrowses van lentísimos, es imposible trabajar.

¿Alguna pista por favor?.

Muchas gracias.

[Loren]

joseluispalma,

Usas tablas DBF-NTX?, DBF-CDX?, usas "dbfilter" en las tablas? Tienes ADS instalado

Yo tengo DBF-CDX con ADS y funciona como un tiro en RED!!

Mi configuración en el PRG principal es:

REQUEST DBFCDX
RddSetDefault("DBFCDX")
REQUEST OrdKeyNo, OrdKeyCount, OrdKeyGoto
REQUEST ADS,ADSKEYCOUNT,ADSGETRELKEYPOS,ADSKEYNO,ADSSetRelKeyPos,rddsys
RDDREGISTER("ADS",1)
SET SERVER LOCAL
AdsSetFileType( ADS_CDX )
AdsLocking( .t. )
AdsRightsCheck( .f. )


un saludo
LORENZO

[joseluispalma]

Hola:

No, no usamos ads, sino DBFCDX.

Las dbfs son pequeñas, menos de 5.000 registros.

La LAN es cableada a 100 Mbps.

[karinha]

Virus? usa WI-FI?

Saludos.

[cnavarro]

Has probado poniendo el .exe en local?

Qué Sistema Operativo usas en el Server?

[joseluispalma]

Hola:

Muchas gracias, el server y los equipos son Windows 7.

Todo está cableado, tienen el Karperski y hemos excluido los dbfs, cdx y fpt.

Estoy loco la verdad.

[Loren]

Hola,

1. ¿Tienes la posilibdad de probrar tu app en otra red local?
2. Elimina los CDX y reindexa de nuevo. Podrían ser CDX corruptos.
3. Comprueba que NO activas ningún "set filter to..." en las consultas xbrowses
4. En un PRG principal inserta la siguiente línea: sethandlecount(180)


suerte.
Un saludo.
LORENZO

[joseluispalma]

Hola, muchas gracias te comento:

1. ¿Tienes la posilibdad de probrar tu app en otra red local?

Sí, y funciona OK.

2. Elimina los CDX y reindexa de nuevo. Podrían ser CDX corruptos.

Ya lo hemos hecho.

3. Comprueba que NO activas ningún "set filter to..." en las consultas xbrowses

No tenemos filtros.

4. En un PRG principal inserta la siguiente línea: sethandlecount(180)

Se supone que sethandlecount(180) sólo es para Clipper, no para Harboour ¿?.

Muchas gracias.

[joseluispalma]

Ayuda por favor!

[hmpaquito]

José Luis,

Aunque nunca he tenido ese problema, uso TS, en los foros de fivetech / harbour problemas similares han sido muchas veces vistos.
Hay muchos mensajes en ambos foros hablando del tema. Es probable que alguno tenga que ver con tu problema.
Quiza Paco Garcia te pueda decir como lo soluciono él https://groups.google.com/forum/#!topic/harbour-users/fUjum_dSEIo


salu2

[joseluispalma]

Hola,

Muchas gracias, sí el problema lo he visto muchas veces reportado, pero nadie comparte la solución.

A ver si una alma caritativa me puede echar una mano por favor.

[hmpaquito]

A nuestros primos de v.foxpro tambien le pasa, y dan solución:

Un problema puede ser de alguna configuración en el servidor, que se da con archivos compartidos en general (no solo tablas dbf).

Vean de hacer lo siguiente:
Lo siguiente se tiene que hacer en cada uno de los clientes con W7 afectados
Primero desactivé la Compresión Diferencial Remota en:
Panel de Control-->Programas y Caraterísticas-->Activar o Desactivar las características de Windows
Se abrirá una nueva ventana y localizamos Compresión Diferencial Remota , la desactivamos y Aceptamos.
Una vez hecho esto, vamos a modificar el autotiming de la tarjeta de red, que según he leido por ahí, por defecto viene como Normal y había que Desactivarlo, pero a mí, así me fue incluso peor, lo que hice fue ponerlo así desde la consola de comandos:
netsh interface tcp set global autotuninglevel=highlyrestricted
Reinicé la máquina, sin mucha fe ni esperanza, ya que estaba ya harto de probar historias y ninguna funcionar y... voilà, la cosa empezó a ir rapidita, funcionaba bien el tema, he dejado pasar unos 4-5 días y de momento sigue funcionando todo correcto y ninguna queja, así que me he puesto a escribir esto por si alguien tiene problemas similares espero que le sirva de algo.
Fuente: http://social.technet.microsoft.com/For ... 0ece01204/

Otra cosa a tener en cuenta:
http://support.microsoft.com/kb/915377/es

o sea, el problema no es de fox o de las dbf, el problema es cambio en el funcionamiento del S.O. que hay que configurar apropiadamente para el caso de uso de archivos compartidos.
Fijense que el problema no es de ahora, viene de vieja data.

Desde https://groups.google.com/forum/#!topic/mundovisualfoxpro/kB_eWOfYnbY

[Kleyber]

jose luis,

Intenta desabilitar el Kaspersky en toda la red y me comentas.

[Willi Quintana]

Hola ,,
Te sugiero revisar los siguientes aspectos..
1.- Si el "servidor" de archivos/datos tiene suficiente memoria (mínimo 4Gb) y velocidad en el procesador (que con el bus de datos etc.)
2.- EL sistema de comunicación entre el server y las estaciones de trabajo (Grupo de Trabajo, IPs)
3.- Los derechos de los usuarios respecto al acceso al servidor.
4.- Espacio de disco (raro hoy en día, pero por si acaso)
5.- Desecha los antivirus (solo para probar), tuve mala experiencia con Norton, Karspesky, (Microsoft Esentials es liviano)
6.- Revisa el uso de archivo temporales, set filter, reindexados etc.
7.- El Sistema Operativo,,, esta con sus parches al dia?, o es preferible tener uno básico....
Salu2

[pgfdz]

Hola.
No se ha solucionado ese problema. Todo apunta a que ha cambiado la forma de tratar los ficheros en las últimas versiones del Sistema Operativo. Hay cosas curiosas en el manejo de las DBFs y los índices. Si hacemos una búsqueda secuencial en un DBF, abriendo como fichero de texto, la primera vez que se busca tarda bastante, luego, las veces posteriores, no tarda nada. Eso es que se W está cacheando el fichero. Supongo que pasa algo parecido con los índices. En definitiva, no he encontrado solución para ello.
De las soluciones que estuve mirando, lo más prometedor era LetoDB que se ejecuta como un servidor y que acelera todo el proceso. No lo he probado en extensión.
Un saludo