Mejorar la velocidad para abrir DBF

[Rogelio Medrano Perez]

Hola amigos Foxeros

 

Como puedo mejorar la velocidad para abrir DBF en una red porque en el servidor abre bien pera en cualquier otra máquina de la red se tarda mucho

 

Rogelio Medrano

 

Saludos

[Alfonso Ramirez Diaz]

Rogelio.

Ese es el gran problema de las tablas DBF que a medida que crecen en una red local se tornan muy lentas.

Lo primero que debes hacer es revisar si todo el cableado y la velocidad de la red están bien, si tienes equipos con wifi deberían cablearlos.

Una solución mejor si sigues usando tablas DBF es hacer uso del Escritorio Remoto del servidor, es decir, todas las estaciones ingresan directamente al escritorio remoto del servidor, con eso las tablas siempre se abrirán en el servidor con lo cual serán muy rápidas y mas seguras en caso de que algún equipo se desconecte, evitando así las corrupciones de tablas y cosas por el estilo.

Y la solución mas radical y lleva mas tiempo y recursos talvez es pasar todo a un motor SQL SERVER o MYSQL con esto ya no tienes problemas a medida que la información crezca.

--
_______________________________________________________________
Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
FoxPro" de Grupos de Google.
 
Para anular la suscripción a este grupo, envía un mensaje a:
mundovisualfox...@googlegroups.com
---
Has recibido este mensaje porque estás suscrito al grupo "Mundo Visual FoxPro" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a mundovisualfox...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Alfonso Ramirez Diaz

Gestpyme - Informatica y Gestión

Fono: 055-833233

Movil: 09-82239821

[Analyzer]

Lo que he leído muchas veces en los foros (aun no implemento un sistema grande en red con tablas nativas), es:

1. Para consultas de datos que no impliquen "modificarlos" o para lanzar reportes, es mejor usar cursores, en vez de las tablas. Se puede navegar libremente por los registros en memoria com si fuera una tabla normal.

Para datos que deban ser modificados, se podría, abrir la tabla, jalar datos a memoria (algo como el scatter memvar) e inmediatamente cerrar la tabla.

Cuando se requiera "volcar" los datos de la memoria a cierto registro, se puede usar un INSERT INTO bla bla from memvar.

Otra opción muy mencionada es usar "Vistas/buffers". 

Tambien recomiendan usar una cosa que llaman "sesión privada de datos".

Realmente, deberías darnos mas luz, para saber como trabajas usualmente y ver que se puede mejorar a partir de ahi..

Solo un grano de arena mas...

Saludos!

--

[César Sánchez Toro]

La recomendación de Escritorio Remoto es la más acertada según mi experiencia.

Efectivamente trabajar con tablas DBF tiene su limitante ya que con el simple “USE” hacer viajar toda la tabla por la red y eso hace que sea muy lento, más aún si tu red no está bien estructurada y sufre de pérdidas de paquetes constantes,  eso ya es un tema de comunicaciones pero tiene mucho que ver en el uso de las tablas DBF.

Mejor usa escritorio remoto, pero eso sí, debe adquirir licencias de MS para poder conectar más de 2 computadoras al servidor.

 

CESAR-ST

[Carlos Alberto Cisneros Madrid]

Pero si uso SELECT

[Alfonso Ramirez Diaz]

Si usas SELECT es lo mismo que si usas un USE al menos la primera vez debe traer todos los registros.

En cuanto al escritorio remoto puedes usar un programa llamado 2X (mas barato que el de microsoft) y hay otro que permite que puedas usar cualquier programa Windows dentro de un navegador de internet (similar al escritorio remoto pero web) pero en estos momentos no lo recuerdo.

[Carlos Miguel FARIAS]

Perdón, pero me parece que al abrir una dbf, solo trae el primer registro, no toda la bd.

Eso es simple de deducir: No tendría razón de ser el tan mentado Rushmore, que se jacta de que las consultas las hace explorando los indices si son apropiados (que si viajan en la parte necesaria) a través de la red y luego, una vez determinados los registros, se leen estos.

Es más. Cuando se hace un select para traer varios registros, se recomienda excluir los memos, para no tener que traer datos que realmente no se leen.

Para aclarar la consulta inicial.

Los cursores son tablas temporales. Por ello es aconsejable que el config.fpw se indique que las tablas temporales se direccionen sobre el disco local.

Por supuesto que lo mejor es seleccionar los datos a mostrar en grillas utilizando SELECT de SQL, cuando se accede a más de una tabla, dichas tablas además deben tener indices apropiados.

Al menos los indices deben estar sobre las claves primarias y sobre los campos que participan en el join. También es conveniente usar indices sobre los campos que se usan como filtros habituales, sobre todo si son indices selectivos (o sea que dado un valor de campo, descartan muchos registros).

Si los datos se muestran frecuentemente en un orden dado, mal no vendría un indice sobre el/los campos de orden.

No se si puede ser conveniente estar abriendo y cerrando las tablas (al menos en cuanto a velocidad).

Si, si se modifican datos, conviene asegurarse de "forzar" los datos sobre disco (p.e. FLUSH, o tableupdate) pero con las debidas validaciones sobre como están los datos en destino.

El uso de buffers es conveniente sobretodo, cuando puede haber mucho acceso concurrente a los mismos conjuntos de registros. Pero usar buffer, si realmente se quieren usar apropiadamente, hay que usarlos con todas las facilidades que dan.

O sea, los buffers, que trabajan algo así como desconectados de las tablas originarias, dan algo de velocidad, pero hay que usar sus facilidades para detectar por ejemplo, si los datos a modificar, no fueron modificados durante la "des-conexión" y evitar de esa manera, pisar datos de otros usuarios.

La sesión privada de datos, te permite "encapsular" las tablas que usas en cada formulario, de manera tal que si en un formulario usas la tabla X y te mueves al registro N, al ir a otro formulario si te mueves al registro K sobre la tabla X, no alteras tu posicionamiento en el primer formulario.

No es mala idea usar escritorio remoto (pero eso carga sobre el servidor)

No es aconsejable mas granos de arena, rayan el disco (;-DD

Saludos: Miguel, La Pampa (RA)

[Alfonso Ramirez Diaz]

Estimado.

El Rushmore es muy bueno pero cuando la tabla DBF es muy grande viaja todo el archivo por la red para ser trabajado en el computador como local en memoria, lo digo porque trabaje con tablas DBF muy grandes y experimente el mismo problema en redes locales disminuia mucho la velocidad, pero una vez abierta trabajaba bien en ciertas condiciones, por eso lo deje y me dedique trabajar con MYSQL y SQL SERVER.

[OscarB]

Yo nunca he tenido ese problema o mejor decir la aplicacion. Esta aplicacion trabaja hasta con 100 pc en una lan , la aplicacion esta desarrollada sobre vfp9, maneja transacciones, bloqueos, moficaciones, inserciones y las consultas si mejoradas como todos las hacen, escogiendo solo las campos o columnas necesarias. La app maneja tablas de hasta 1000.000 o un poco mas registros sin deterioro de tiempo en sus procesos. Trucos: control de indixes (cdx) , buena red lan (100mb). Y si alguno de los usuarios quiere acceso via internet cree un pc con acceso remoto via terminal server a este.
Solo en estos dias he pensado migrar estas tablas a sql server por el tema de construccion de herramientas web de apoyo a la app de escritorio actual, por ejemplo para informes de ventas via web a cierto grupo de usuarios (vendedores) o directivos,otro ejemplo para consultar informes desde dispositivos moviles como tablet, o celulares, en fin
Espero sirva de guia mi experiencia con vfp y tablas.

[Daniel Manuel López]

Para acelerar la apertura de sus archivos deben
abrirlos con la dirección completa de su servidor
ejem: \\Servidor\Aplicacion\Datos\tabla.dbf

Saludos

> Date: Sun, 2 Jun 2013 19:38:40 -0700
> From: sist...@sagal.com.co
> To: mundovis...@googlegroups.com
> Subject: [Mundo Visual FoxPro] Mejorar la velocidad para abrir DBF

>
> Yo nunca he tenido ese problema o mejor decir la aplicacion. Esta aplicacion trabaja hasta con 100 pc en una lan , la aplicacion esta desarrollada sobre vfp9, maneja transacciones, bloqueos, moficaciones, inserciones y las consultas si mejoradas como todos las hacen, escogiendo solo las campos o columnas necesarias. La app maneja tablas de hasta 1000.000 o un poco mas registros sin deterioro de tiempo en sus procesos. Trucos: control de indixes (cdx) , buena red lan (100mb). Y si alguno de los usuarios quiere acceso via internet cree un pc con acceso remoto via terminal server a este.
> Solo en estos dias he pensado migrar estas tablas a sql server por el tema de construccion de herramientas web de apoyo a la app de escritorio actual, por ejemplo para informes de ventas via web a cierto grupo de usuarios (vendedores) o directivos,otro ejemplo para consultar informes desde dispositivos moviles como tablet, o celulares, en fin
> Espero sirva de guia mi experiencia con vfp y tablas.
>

[Marcelo Sabella]

y siquieres agregarle mas velocidad y obviar la etapa de resolución DNS, le puede especificar la IP resuelta, ejem: \\192.168.0.100\Aplicacion\Datos\tabla.dbf

[Miguel Santander]

Perdón, por la intromisión

Yo también tengo el mismo problema de lentitud, pero yo tengo mis tablas en cada  formulario (entorno de datos)

[Carlos Miguel FARIAS]

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/Forums/es-ES/windowsserveres/thread/c90fb04b-957b-4d19-840d-7260ece01204/

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.

Saludos: Miguel, La Pampa (RA)

[Analyzer]

Excelente ! Gracias por compartir.

El 04/06/13, Carlos Miguel FARIAS <carlosmig...@gmail.com> escribió:

> 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/Forums/es-ES/windowsserveres/thread/c90fb04b-957b-4d19-840d-7260ece01204/
>
> 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.
> Saludos: Miguel, La Pampa (RA)
>
>
> El 4 de junio de 2013 10:37, Miguel Santander
> <miguel.s...@tigo.com.py>escribió:
>

>> Perdón, por la intromisión****

>>
>> Yo también tengo el mismo problema de lentitud, pero yo tengo mis tablas

>> en cada formulario (entorno de datos)****
>>
>> ** **
>>
>> ** **
>>
>> *De:* mundovis...@googlegroups.com [mailto:
>> mundovis...@googlegroups.com] *En nombre de *Marcelo Sabella
>> *Enviado el:* lunes, 03 de junio de 2013 20:53
>> *Para:* mundovis...@googlegroups.com
>> *Asunto:* Re: [Mundo Visual FoxPro] Mejorar la velocidad para abrir
>> DBF***
>> *
>>
>> ** **

>>
>> y siquieres agregarle mas velocidad y obviar la etapa de resolución DNS,
>> le puede especificar la IP resuelta, ejem:

>> \\192.168.0.100\Aplicacion\Datos\tabla.dbf****
>>
>>
>>
>> ****

>>
>> El 3 de junio de 2013 13:51, Daniel Manuel López <dman...@hotmail.com>

>> escribió:****

>>
>> Para acelerar la apertura de sus archivos deben
>> abrirlos con la dirección completa de su servidor
>> ejem: \\Servidor\Aplicacion\Datos\tabla.dbf
>>

>> Saludos****

>>
>> > Date: Sun, 2 Jun 2013 19:38:40 -0700
>> > From: sist...@sagal.com.co
>> > To: mundovis...@googlegroups.com

>> > Subject: [Mundo Visual FoxPro] Mejorar la velocidad para abrir DBF ****

>> > ****

>>
>> --
>> _______________________________________________________________
>> Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
>> FoxPro" de Grupos de Google.
>>
>> Para anular la suscripción a este grupo, envía un mensaje a:
>> mundovisualfox...@googlegroups.com
>> ---
>> Has recibido este mensaje porque estás suscrito al grupo "Mundo Visual
>> FoxPro" de Grupos de Google.
>> Para anular la suscripción a este grupo y dejar de recibir sus correos
>> electrónicos, envía un correo electrónico a
>> mundovisualfox...@googlegroups.com.
>> Para obtener más opciones, visita
>> https://groups.google.com/groups/opt_out
>> .
>>

>> ****
>>
>> ** **

>>
>> --
>> _______________________________________________________________
>> Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
>> FoxPro" de Grupos de Google.
>>
>> Para anular la suscripción a este grupo, envía un mensaje a:
>> mundovisualfox...@googlegroups.com
>> ---
>> Has recibido este mensaje porque estás suscrito al grupo "Mundo Visual
>> FoxPro" de Grupos de Google.
>> Para anular la suscripción a este grupo y dejar de recibir sus correos
>> electrónicos, envía un correo electrónico a
>> mundovisualfox...@googlegroups.com.
>> Para obtener más opciones, visita
>> https://groups.google.com/groups/opt_out
>> .
>>

>> ****

Saludos!

[César Sánchez Toro]

Tienes mucha razón con esto. El manejo de DBF’s tiene mucho que ver con cómo está configurada tu red. Si no hay una buena red estructurada, con cables configurados en categoría 5 o 6 correctamente entonces todo será lento. Muchas veces ponchamos cables solo de un lado igual al otro sin importar el orden de los colores y aquí en donde se cometen errores y luego la red es afectada. Se que esto es tema de redes y comunicaciones pero tienen mucho que ver con la velocidad en el uso de DBF’s.

 

CESAR ST