Lentitud en Select cuando la tabla esta abierta por dos usuarios

[Visual FoxPro Nuevo]

Buenos dias a todos,

Mi problema es el que sigue:

Tengo un Select hacia una tabla de unos 200.000,00 Registros la cual
pesa aprox. unos 64MB y el CDX unos 15MB.

La consulata esta totalmente optimizada Rushmore Garantizado!!!

El Select se ejecuta aproximadamente en unos 3Seg desde una estacion
de trabajo leyendo los datos que estan en el Server.

Cuando otro usuario abre la tabla del select todo se vuelve
suuuuuuuuper lento, les puedo decir que de 3Seg la consulta pasa a
demorarse una media hora.


He realizado las siguientes pruebas:

1. Abrir la tabla sin usar buffers de datos --> Igual de lento
2. Abrir la tabla en la misma estacion de trabajo -->Igual de lento
3. Usar Set Multilock ON --> Igual de Lento
4. Cambiar los datos a otro Server (Dentro de la misma RED) -->Igual
de Lento
5. Revise si la tabla esta corrupta (Esta OK) --> Igual de lento
6. Usar Indice Delete() --> Era necesari para optimizar Rushmore e
igual sigue lento
7. Instale el programa en el Server y lo ejecuto desde alli y aun asi
si me meto dos veces a la aplicacion el Select se vuelve Leeeeento.

Pareciera que existe algo que al abrir la tabla en otra estacion
(Simplemente con un
USE ...Shared) hace que el Select se tarde muchisimo.

En realidad no se que mas probar, he revisado en este foro y casi
todos los problemas de lentitud se deben a la optimizacion del
Select, Rushmore, creacion de indices, etc...

Mi caso pareciera ser diferente porque funciona perfectamente cuando
el unico proceso que abre la tabla es el que ejecuta el Select, si
entra otro usuario desde otro equipo o si desde la misma estacion se
abre de nuevo la tabla, entonces viene el problema.

Para mayor informacion:

1. El programa esta hecho en VFP8.
2. El Server Windows 2003.
3. Las estaciones de trabajo WinXP.
4. La red esta certificada Nivel 5, Switches, velocidad probada.
5. Los temporales con los respectivos SET estan direccionados a la
maquina local dentro del Config.FPW

En verdad estoy un poco desesperado pues ya no se que mas revisar para
solventar este problema.

Mucho agradezco todas las sugerencias que puedan hacerme a fin de
ayudarme a mejorar esta situacion ya que esto esta generando problemas
en el cliente. Basicamente para generar la consulta los usuarios
deben verificar antes si existe alguien trabajando con la aplicacion
(Totalmente obsoleto en esta epoca de la tecnologia).

Llevo desarrollando en VFP casi 10 anios y esto nunca antes me habia
pasado :(

Gracias por su colaboracion.

[Luis Mata]

No tiene solucion, esa fue la razon por la que me mude a SQL Server.

Luis

[Manuel Zevallos]

Quizas podrias hacer subconsultas de sql y trabajarlas en bloque que trabajar uno solo.

El 11 de septiembre de 2010 00:47, Luis Mata <lma...@gmail.com> escribió:

No tiene solucion, esa fue la razon por la que me mude a SQL Server.

Luis

-----Original Message----- From: Visual FoxPro Nuevo
Sent: Friday, September 10, 2010 8:07 PM

To: Comunidad de Visual Foxpro en Español

--

Atte.,

Manuel Zevallos

[Luis Maria Guayan]

Pregunta:

¿El Windows Server 2003 es controlador principal de dominio?

Si la respuesta es sí, es un bug de Windows 2003 Server

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

 

[elkin dario uribe torres]

Buenos dias

Hace poco hice una consulta en el foro con respecto a la lentitud  de un select pero porque el mio tardaba a lo sumo 20 segundo, atacando una tabla de 450.000 registros y lo mejore colocando los indices que me faltaban en la cunsulta, ahora he comprobado que cuando hago el select y lo envio a un cursor no demora nada, pero el tiempo incrementa considerablemente si lo hago a una tabla.

Esta consulta la efectuan al mismo tiempo llegado el caso 8 estaciones trabajando en linea, ya que es para atencion al publico, te imaginas si tuvieran que esperar media hora cada uno, si en promedio se atienden 150 personas al dia y otras tantas por telefono.  No creo que sea de Foxpro el problema revisa por otro lado.

Elkin uribe
Medellin - Colombia

[Guillermo MDQ]

Luis, tenes mas informacion sobre ese bug que comentas en Win Server
2003 cuandoe s controlador de dominio ?
Se soluciono con algun service pack ?

Saludos
Guillermo

On 11 sep, 10:32, Luis Maria Guayan <luisma...@portalfox.com> wrote:
> Pregunta:
> ¿El Windows Server 2003 es controlador principal de dominio?
> Si la respuesta es sí, es un bug de Windows 2003 Server
>
> Luis María Guayán
> Tucumán, Argentina

> _________________________http://www.PortalFox.com

[Visual FoxPro Nuevo]

Luis, podrias por favor enviar informacion relacionada con el bug de
Windows 2003 Server?

Cuales son los fixed y como saber si estan instalados?

Saludos y Gracias,
AF

[Luis Maria Guayan]

Te paso unos artículos de la MSKB que ya he enviado alguna vez:

Esto es un Bug de Windows 2003 Server en equipos que son controladores primarios de dominios. En algunos casos hay parches que debes pedir a Microsoft. Te paso algunos artículos de la Base de Conocimientos de Microsoft, pero busca por mas, a ver cual se asemeja mas a tu caso.

-- Los equipos basados en Windows Server 2003 funcionan más lentamente y dejan de responder después de ejecutarse durante varios día --
http://support.microsoft.com/kb/821008/es

-- El rendimiento puede ser lento en un controlador principal de sitio que ejecuta servicio de Message Queuing Server --
http://support.microsoft.com/kb/832716/es

-- Puede experimentar rendimiento lento por algunos programas en Microsoft Windows Server 2003 --
http://support.microsoft.com/kb/831168/es


--

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Victor E. Torres Tejada]

Hola,

Rushmore y todo eso funciona pero cuando comienza a crecer la cantidad de registros

en cada tabla y estan en entorno multusuario hay que evaluar otras alternativas;

 

Tienes que descartar que sea un problema de red, a veces cambiando el switch, cableado y/o tarjetas de red se arregla el problema, obviamente se debe hacer pruebas antes de hacer los cambios, con copias de archivos de gran tamaño entre los distintos puntos de la red, para evaluar la velocidad de transmision,

y colisiones en algun punto de red, se requiere la asistencia de un tecnico especializado en estas

cosas de networking para no meter la pata.

 

Si no es un problema de velocidad de red , debes evaluar el codigo de tus sentencias select,

ya que en Visual Foxpro con DBFs libres o en contenedor .DBC , lo mas rapido es usar el

seek , con el SCAN y el IF dentro del SCAN para filtrar datos, haciendo las combinaciones

adecuadas puedes disminuir el tiempo de respuesta de forma notoria.

 

Ya cuando haz agotado esos 2 primeros pasos y sigues sin obtener un tiempo de respuesta

optimo , es que ya lllego la hora de mirar otros servidores de base de datos , ahi tienes,

Advantage server, MySql, Sql Server, Oracle, etc.

 

Pero , pensar en cambiar de base de datos directamente sin hacer el tunning adecuado

a tu codigo que consulta las tablas y /o revisar problemas de red es algo apresurado,

sin contar el tema de los usuarios concurrente a la vez a un registro de una tabla.

 

Han habido casos en donde sin profundizar  mucho en el origen del problema se cambia

directamente a Sql Server u Oracle y resulta que sigue siendo igual de lento o con una mejora

de rendimiento minima, y al final terminan cambiando el cableado de la red, cambian a un

switch Cisco (1000 US$ para arriba, la velicidad cuesta) , le agregan memoria al servidor

y recien ahi se percibe una mejora en el tiempo de respuesta , la solucion

al final termina haciendo mella en la relacion costo / beneficio  y queda la incertidumbre

de si HUBIERA hecho primero esto o aquello antes de migrar a otro servidor de base de datos,

finalmente se queda en un caso para Mythbuster.

 

Nos vemos,

 

2 alternativas te cambias a una

base de datos mas potente

El 10 de septiembre de 2010 22:07, Visual FoxPro Nuevo <ange...@gmail.com> escribió:

--

Victor E. Torres Tejada

www.o-negocios.com

4216093 - 993290086

 

Buscador de productos       

Envianos tu pedido aqui

[Victor E. Torres Tejada]

Asi es, podria ser eso , Luis Maria tiene  razon, esta documentado por ahi, busca en el sitio de microsoft.

[Luis Mata]

Pero algo debe estar bien claro, sea bug, red o lo que fuere cuantos mas datos tengas mas lento estara tu sistema, la red lo descartas rapido si el correo , internet y otras aplicaciones estan ok, queda descartado la red y proyectate en migrar a otra BD si lo planificas bien te sera facil.

 

No se de donde eres pero si quieres asesoria con gusto yo migre a sql y no tuve muchos inconvenientes cambie pocas cosas en el codigo al contrario elimine codigo.

 

 

Luis Mata

[IVAN MARTINEZ]

1) Lo primero que haria es poner el sistema en otra red.

Para descartar problemas locales.

Hoy en dia es facil quien no tiene una red en la casa.

 

2) Si persiste el problema miraria como estas haciendo las cosas.

Si dices que por abrir solo la basede datos ya se presenta el problema.

 

Haria un use simple

 

y el select problematico lo haria sacandolo del programa de donde esta y de ahi en adelante.

 

haria cualquier cosa mas.

 

Incluso si me mandas lo basico del problema yo podria probar en mis maquinas.

 

 

 

Ivan Martinez von Halle

 

 

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Victor E. Torres Tejada
Enviado el: Domingo, 12 de Septiembre de 2010 09:10 p.m.
Para: publice...@googlegroups.com
Asunto: Re: [vfp] Lentitud en Select cuando la tabla esta abierta por dos usuarios

[Jorge Méndez]

Hola!

> ¿El Windows Server 2003 es controlador principal de dominio?
> Si la respuesta es sí, es un bug de Windows 2003 Server

No necesariamente, yo he experimentado este mismo problema en redes
simples de 2 ordenadores 100% XP Professional, en el que uno de ellos
funciona a la vez como servidor y estación.

Paso 1 en Ordenador 1:
Use tabla -> Unos 15.000 registros
select * from tabla where Rushmore_condición -> Apenas unas décimas
de segundo

Paso 2 en Ordenador 2
Use tabla

Paso 3 en Ordenador 1
select * from tabla where Rushmore_condición -> Lo que antes eran
décimas de segundo ahora se convierten en entre 40 y 50 segundos


Tampoco encontré ninguna solución a este desesperante problema.

Un saludito!

[Jaime H. Díaz G.]

Buenos días Luis María...tengo el mismo problema pero con 2008 server....tendrá los mismos orígenes...?

[EXTREMO]

yo nunca he tenido ese tipo de problemas ya que cuando trabajo con
tablas DBF siempre abro y cierro la tabla inmediatamente, por ejemplo
para tu caso yo haria lo siguiente.

use MiTabla in 0
select * from MiTabla where idTabla = MiDatoABuscar into cursor
MiCursorDeTrabajo
use in MiTabla

Asi libero el uso de la tabla y con ello ademas me aseguro de mantener
siempre lo menos posible la tabla DBF abierta para disminuir la
posibilidad de una corrupcion de algun archivo por corte de luz o
similares.


Bendiciones

[Victor Espina]

Luis Maria, el autor de la pregunta es amigo personal mio. De hecho,
muchas de las pruebas que el reporto haber hecho fueron sugeridas por
mi poco antes de venirme a chile.

Lo del Windows Server 2003 tendria sentido si no fuera porque,
justamente para descartar esta posibilidad, le pedi que probara el
problema mudando los datos a otro equipo en la red (que no estaba
ejecutando Win 2003 server) y tambien accesando los datos de manera
local. En ambos casos el resultado fue el mismo, por lo que queda
descartado tanto un problema de red como un problema del server 2003.

Realmente el problema es bien raro, y aunque ya hace tiempo que no
diseno aplicaciones que trabajen con DBFs, no recuerdo que algo como
esto me haya sucedido antes.

Saludos

Victor Espina

On 11 sep, 09:32, Luis Maria Guayan <luisma...@portalfox.com> wrote:
> Pregunta:
> ¿El Windows Server 2003 es controlador principal de dominio?
> Si la respuesta es sí, es un bug de Windows 2003 Server
>
> Luis María Guayán
> Tucumán, Argentina

> _________________________http://www.PortalFox.com

[Luis Mata]

el problema con BDF no se ve si el acceso la data es peque�a pero si
hablamos de cientos de miles de registros, DBF no sirve.

Luis

----- Original Message -----
From: "Victor Espina" <vesp...@gmail.com>
To: "Comunidad de Visual Foxpro en Espa�ol"
<publice...@googlegroups.com>
Sent: Monday, September 13, 2010 11:44 AM
Subject: [vfp] Re: Lentitud en Select cuando la tabla esta abierta por dos
usuarios

Luis Maria, el autor de la pregunta es amigo personal mio. De hecho,
muchas de las pruebas que el reporto haber hecho fueron sugeridas por
mi poco antes de venirme a chile.

Lo del Windows Server 2003 tendria sentido si no fuera porque,
justamente para descartar esta posibilidad, le pedi que probara el
problema mudando los datos a otro equipo en la red (que no estaba
ejecutando Win 2003 server) y tambien accesando los datos de manera
local. En ambos casos el resultado fue el mismo, por lo que queda
descartado tanto un problema de red como un problema del server 2003.

Realmente el problema es bien raro, y aunque ya hace tiempo que no
diseno aplicaciones que trabajen con DBFs, no recuerdo que algo como
esto me haya sucedido antes.

Saludos

Victor Espina

On 11 sep, 09:32, Luis Maria Guayan <luisma...@portalfox.com> wrote:
> Pregunta:
> �El Windows Server 2003 es controlador principal de dominio?

> Si la respuesta es s�, es un bug de Windows 2003 Server
>
> Luis Mar�a Guay�n
> Tucum�n, Argentina

> _________________________http://www.PortalFox.com
> Nada corre como un zorro
> _________________________
>
>
>
>
>
>

> El 11/09/2010 00:07, Visual FoxPro Nuevo escribi�:Buenos dias a todos, Mi

[Luis Maria Guayan]

Tengo un colega aquí en mi ciudad  que tuvo un problema de lentitud con un servidor Windows Server 2008 con copias de archivos y lo pudo solucionar (despues de muchas búsquedas y consultas) con este hilo de un foro de Windows Server

-- Very slow DFSR on Windows Server 2008 --
http://social.technet.microsoft.com/Forums/en-US/winserverfiles/thread/e55022a4-db65-4dc9-a2f1-96b7f5d8e2fa

No se si te pueda servir esta solución

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

 

[Luis Maria Guayan]

Como bien indicas Victor, es extraño el problema. Yo no lo he tenido en mis aplicaciones.

Con respecto a lo que indica Luis Mata, yo he tenido sistemas con DBFs, tanto de VFP y de FPW26, con mas de dos millones de registros y los tiempos  de respuestas de las consultas eran optimos. Cuando surgia algún problema con la performance, se debía a índices corruptos o estaciones de trabajo con problemas de conectividad.

Sabido es que las DBF de VFP se corrompen y no tienen seguridad, pero de allí a decir que con cientos de miles de registros las DBF no sirven, no es correcto.

[Luis Mata]

Luis Maria no es que quiera desacreditar lo que tu dices, pero trabajar en red con millones de registros solo se puede hacer mediante una cadena de conexion sin tener que abrir las tablas fisicamente, porque bien es sabido que trabajando de la forma nativa de VFP se tiene que abrir primero el DBF y luego recien extraer el registro que se desea y cerrar la tabla, ahora mientras que sea una pequeña tabla esta operacion no tardara mucho porque el archivo es pequeño ahora eso pasalo a un archivo dbf de cientos de megas solo en abrir y cerrar se va a demorar lo que se demoraria abrir un arhivo xls de ese tamaño.

Yo lo digo porque ese fue mi problema y muy grave ya que sumandole el tema de corrupcion de tablas que es mucho mas frecuente ya que al demorar la apertura de tablas los usuario asumen cuelgues y resetena la Pc, se suma el trabajo de estar regenerando lo indices dañados  y otras cosas.

No nos engañemos al decir que los DBF  son buenos si explicar bien la metodologia para poder manipular los datos, con una cadena de conexion trabaja de manera aceptable pero es igual que trabajar con una BD robusta asi que mejor es trabajar con SQL Server , Mysql o Postgres.

Sumando todos esos problemas que me terminaron por estresar es que dentro de mi concepcion o al menos para mi los DBF son inaceptables para proyectos futuros de gran envergadura.

Trato de ser objetivo de no levantar polemica , pero los DBF tuvieron su gloria y se puede decir que son la vieja gloria.

 

LuiS Mata

[Luis Maria Guayan]

Comprendido y sin polémicas.

Hay aplicaciones y PYMEs (pequeñas y medianas empresas) que con tablas nativas de VFP se pueden desarrollar y mantener correctamente, siempre sumando respaldos adecuados, sistemas de energia ininterrumpidos y un buen cableado de red.

Hay otras aplicaciones, que con solo la falta de seguridad de las DBF, ya hay que pensar en un motor de bases de datos externo.

Saludos,

[Victor Espina]

Victor, si lees bien el correo inicial veras que el codigo funciona
correctamente y tarda menos de 1 min siempre, tanto si los datos estan
locales como si estan en el servidor; el problema solo se presenta
cuando al momento de ejecutar el SELECT la tabla estaa abierta por
otro usuario, no importa si los datos estan locales o en el servidor.

Esto descarta:
a) Problemas de red (pues el error se presenta incluso en forma local)
b) Problemas de optimizacion del select (pues el codigo funciona bien
si la tabla no esta abierta)
c) Problemas de performance del servidor (pues el error se presenta
incluso teniendo los datos localmente)
d) Problemas de tiempo de espera por bloqueo (pues solo se estan
consultando datos y no actualizandolos)


Saludos

Victor Espina



On 12 sep, 21:39, "Victor E. Torres Tejada" <vtor...@o-negocios.com>
wrote:

> <angel...@gmail.com>escribió:

>  Buscador de productos<http://www-mcd.deltron.com.pe/modulos/productos/items/ctBuscador/temp...>
>
> Envianos tu pedido aqui <vtor...@o-negocios.com>

[EXTREMO]

Si ubieran leido mi respuesta no estarian siguiendo con el debate, se
los volvere a escribir

El problema es super simple, con un usuario la consulta es rapida, con
mas de un usario, la consulta es lenta. Este problema ocurre porque en
el sistema la tabla a consultar no se cierra despues de haber
realizado la consulta, si pruebas con este metodo de abrir -
cerrar ,te aseguro que ya no tendras problemas de lentitud

Bendiciones

[Mario López]

@Luis:

>> "bien es sabido que trabajando de la forma nativa de VFP se tiene que abrir
>> primero el DBF y luego recien extraer el registro que se desea y cerrar la tabla"

mmm, no es así como decís. Para "abrir" un .DBF (o sea, USE Tabla), lo
único que
VFP efectúa es el equivalente a un FOPEN del archivo sumado un FREAD
del
header para extraer la estructura del mismo.

Si EN TU CASO te tarda es porque estarás abriendo una vista no
parametrizada
(que equivaldría a hacer un SELECT * FROM Tabla) o porque la misma no
tiene
los índices correspondientes (que equivaldría a hacer un SCAN FOR de
la
tabla completa)

Yo tengo todavía algunos sistemas con DBFs que manejan varios millones
de
registros y -con los índices adecuados- no tuve mayor problema que el
límite
de 2 Gby. Con una red estable no tuve tampoco jamás problemas graves
de corrupción de registros: la gran mayoría son inconsistencias del
header del .DBF que pueden repararse con CmRepair o vía una rutina
propia.

De hecho, por lo menos en dos casos con MySql, tuve problemas graves
de corrupción en la base de datos que me obligaron a restaurar la
misma
desde un backup.

Mis 2 centavos,
Mario

---

[Luis Mata]

Y como abres la tabla de 2 millones y de 2 GB en una red, ni bien le das:

use mitabla shared in 0

y le das browse te muestra los 2 millones, entonces debes saber algo que yo
no se al abrir una tabla no tiene nada que ver los indice los indices son
para Busquedas.

Luis

----- Original Message -----
From: "Mario L�pez" <guag...@gmail.com>
To: "Comunidad de Visual Foxpro en Espa�ol"

<publice...@googlegroups.com>
Sent: Monday, September 13, 2010 3:22 PM
Subject: [vfp] Re: Lentitud en Select cuando la tabla esta abierta por dos
usuarios

@Luis:

>> "bien es sabido que trabajando de la forma nativa de VFP se tiene que
>> abrir
>> primero el DBF y luego recien extraer el registro que se desea y cerrar
>> la tabla"

mmm, no es as� como dec�s. Para "abrir" un .DBF (o sea, USE Tabla), lo
�nico que
VFP efect�a es el equivalente a un FOPEN del archivo sumado un FREAD

del
header para extraer la estructura del mismo.

Si EN TU CASO te tarda es porque estar�s abriendo una vista no
parametrizada
(que equivaldr�a a hacer un SELECT * FROM Tabla) o porque la misma no
tiene
los �ndices correspondientes (que equivaldr�a a hacer un SCAN FOR de
la
tabla completa)

Yo tengo todav�a algunos sistemas con DBFs que manejan varios millones
de
registros y -con los �ndices adecuados- no tuve mayor problema que el
l�mite
de 2 Gby. Con una red estable no tuve tampoco jam�s problemas graves
de corrupci�n de registros: la gran mayor�a son inconsistencias del
header del .DBF que pueden repararse con CmRepair o v�a una rutina
propia.

De hecho, por lo menos en dos casos con MySql, tuve problemas graves

de corrupci�n en la base de datos que me obligaron a restaurar la
misma
desde un backup.

Mis 2 centavos,
Mario

---

On 13 sep, 16:37, "Luis Mata" <lm...@cclf.com.pe> wrote:
> Luis Maria no es que quiera desacreditar lo que tu dices, pero trabajar en
> red con millones de registros solo se puede hacer mediante una cadena de
> conexion sin tener que abrir las tablas fisicamente, porque bien es sabido
> que trabajando de la forma nativa de VFP se tiene que abrir primero el DBF
> y luego recien extraer el registro que se desea y cerrar la tabla, ahora

> mientras que sea una peque�a tabla esta operacion no tardara mucho porque
> el archivo es peque�o ahora eso pasalo a un archivo dbf de cientos de

> megas solo en abrir y cerrar se va a demorar lo que se demoraria abrir un

> arhivo xls de ese tama�o.

> Yo lo digo porque ese fue mi problema y muy grave ya que sumandole el tema
> de corrupcion de tablas que es mucho mas frecuente ya que al demorar la
> apertura de tablas los usuario asumen cuelgues y resetena la Pc, se suma

> el trabajo de estar regenerando lo indices da�ados y otras cosas.
> No nos enga�emos al decir que los DBF son buenos si explicar bien la

> metodologia para poder manipular los datos, con una cadena de conexion
> trabaja de manera aceptable pero es igual que trabajar con una BD robusta
> asi que mejor es trabajar con SQL Server , Mysql o Postgres.
> Sumando todos esos problemas que me terminaron por estresar es que dentro
> de mi concepcion o al menos para mi los DBF son inaceptables para
> proyectos futuros de gran envergadura.
> Trato de ser objetivo de no levantar polemica , pero los DBF tuvieron su
> gloria y se puede decir que son la vieja gloria.
>
> LuiS Mata
>
> ----- Original Message -----
> From: Luis Maria Guayan
> To: publice...@googlegroups.com
> Sent: Monday, September 13, 2010 2:06 PM
> Subject: Re: [vfp] Re: Lentitud en Select cuando la tabla esta abierta por
> dos usuarios
>

> Como bien indicas Victor, es extra�o el problema. Yo no lo he tenido en

> mis aplicaciones.
>
> Con respecto a lo que indica Luis Mata, yo he tenido sistemas con DBFs,
> tanto de VFP y de FPW26, con mas de dos millones de registros y los

> tiempos de respuestas de las consultas eran optimos. Cuando surgia alg�n
> problema con la performance, se deb�a a �ndices corruptos o estaciones de

> trabajo con problemas de conectividad.
>
> Sabido es que las DBF de VFP se corrompen y no tienen seguridad, pero de

> all� a decir que con cientos de miles de registros las DBF no sirven, no
> es correcto.
>

> Luis Mar�a Guay�n

> Tucum�n, Argentina

> _________________________
> http://www.PortalFox.com
> Nada corre como un zorro
> _________________________
>

> El 13/09/2010 13:44, Victor Espina escribi�:

> Luis Maria, el autor de la pregunta es amigo personal mio. De hecho,
> muchas de las pruebas que el reporto haber hecho fueron sugeridas por
> mi poco antes de venirme a chile.
>
> Lo del Windows Server 2003 tendria sentido si no fuera porque,
> justamente para descartar esta posibilidad, le pedi que probara el
> problema mudando los datos a otro equipo en la red (que no estaba
> ejecutando Win 2003 server) y tambien accesando los datos de manera
> local. En ambos casos el resultado fue el mismo, por lo que queda
> descartado tanto un problema de red como un problema del server 2003.
>
> Realmente el problema es bien raro, y aunque ya hace tiempo que no
> diseno aplicaciones que trabajen con DBFs, no recuerdo que algo como
> esto me haya sucedido antes.
>
> Saludos
>
> Victor Espina
>
> On 11 sep, 09:32, Luis Maria Guayan <luisma...@portalfox.com> wrote:
> Pregunta:
> �El Windows Server 2003 es controlador principal de dominio?

> Si la respuesta es s�, es un bug de Windows 2003 Server
>
> Luis Mar�a Guay�n

> Tucum�n, Argentina

> _________________________http://www.PortalFox.com
> Nada corre como un zorro
> _________________________
>

> El 11/09/2010 00:07, Visual FoxPro Nuevo escribi�:Buenos dias a todos, Mi

[Mario López]

@Luis:

hace mucho que no trabajás con DBFs, no? ;)

Hacer:

USE MiTabla
BROWSE

requiere solamente el equivalente a hacer:

* Un FOPEN de la tabla
* Un FREAD para obtener el header de la tabla y generar
la estructura de la misma
* Un FREAD por cada registro visible en el BROWSE

Así entonces, si hacés un

GO BOTTOM

equivaldría a hacer:

* Un FSEEK(x, HEADER() + (RECCOUNT()-1)*RECSIZE()) para posicionar
en el registro indicado
* Un FREAD por cada registro visible en el BROWSE


Igualmente, para que te quedes tranquilo, acabo de verificarlo
(por milésima vez) abriendo por la red un archivo de 800 Mby,
haciendo un GO BOTTOM y un BROWSE del mismo y oh, sorpresa!
se ejecutan instantáneamente.

No te quedes con lo que yo te digo, probalo y fijate por vos mismo.
Por lo único que contesté es para que no quede en el foro como
"algo bien sabido" una cosa que es totalmente incorrecta
(independientemente
que para un sistema de mediana a gran envergadura coincido en que un
esquema cliente / servidor sea la primera opción a considerar).

Saludos,
Mario

[Victor Espina]

Amigo, esa no es una solucion. Incluso haciendo eso, queda la
posibilidad de que dos usuarios intenten ejecutar ese mismo codigo al
mismo tiempo, lo cual terminaria en el mismo problema que tiene
ahora.

Si bien es cierto que por regla general es recomendable mantener los
dBFs abiertos el menor tiempo posible, lo cierto es que VFP permite
PERFECTAMENTE mantener un DBF abierto en forma compartida entre varios
usuarios sin que eso repercuta en los tiempos de respuesta.

Saludos

Victor Espina

[Luis Mata]

ummm acabo de ver esas funciones, pero eso es para leer la data y �para
hacer un update, insert, delete.?
Aparentemente es un pseudo select, ni hablar demasiado limitado.

Luis

----- Original Message -----
From: "Mario L�pez" <guag...@gmail.com>
To: "Comunidad de Visual Foxpro en Espa�ol"
<publice...@googlegroups.com>
Sent: Monday, September 13, 2010 4:00 PM
Subject: [vfp] Re: Lentitud en Select cuando la tabla esta abierta por dos
usuarios

@Luis:

hace mucho que no trabaj�s con DBFs, no? ;)

Hacer:

USE MiTabla
BROWSE

requiere solamente el equivalente a hacer:

* Un FOPEN de la tabla
* Un FREAD para obtener el header de la tabla y generar
la estructura de la misma
* Un FREAD por cada registro visible en el BROWSE

As� entonces, si hac�s un

GO BOTTOM

equivaldr�a a hacer:

* Un FSEEK(x, HEADER() + (RECCOUNT()-1)*RECSIZE()) para posicionar
en el registro indicado
* Un FREAD por cada registro visible en el BROWSE

Igualmente, para que te quedes tranquilo, acabo de verificarlo

(por mil�sima vez) abriendo por la red un archivo de 800 Mby,

haciendo un GO BOTTOM y un BROWSE del mismo y oh, sorpresa!

se ejecutan instant�neamente.

No te quedes con lo que yo te digo, probalo y fijate por vos mismo.

Por lo �nico que contest� es para que no quede en el foro como

"algo bien sabido" una cosa que es totalmente incorrecta
(independientemente
que para un sistema de mediana a gran envergadura coincido en que un

esquema cliente / servidor sea la primera opci�n a considerar).

[Walter R. Ojeda Valiente]

Hola Luis

Es lo mismo, para hacer un insert se usa un FSeek() al último registro y luego un FWrite(), para modificar o borrar un registro (es lo mismo) se hace un FSeek() y luego un FWrite().

Los .DBF son muy rápidos cuando se trata de agregar, borrar, modificar o consultar registros. Su problema es la falta de seguridad y que tienden a corromperse cuando hay cortes de luz o cuelgues de programas, pero la velocidad no es un problema para ellos, siempre funcionan muy rápido. Es más, normalmente son más rápidos que cualquier SQL.

Saludos.

Walter.

[IVAN MARTINEZ]

En general las dbf son mas rapidas que cualquier motor conocido siedmpre y cuando se manejen bajo la misma premisa.

 

Si con mysql solo accesas a un registro pues para hacer la comparacion debes hacer algo semejante en vfp.

Sino de que comparacion estamos hablando.

 

Es sabido que dada la rapidez de foxpro es que tiene tantos vicios de los cuales nos es dificil desprendernos.

 

Si a vfp lo manejas con SPT, con ado, con ole db, coin vistas remotas bien diseñadas los tiempos van aser semejantes.

 

Ahora como dijo Carlos Mata si abres una base de datos de 2 millones de registros en un form de facturacion encabezado , detalles y los relacionas con set relation sin ningun filtrado en el servidor esto va ha ser lentisimo , ya me paso.

 

En mi maquina volaba , pero cuando fui a la red real fue un desastre.

 

Es la forma de programar los accesos no el que sea dbf o no dbf. Esto hablando del tema de velocidad.

 

Ivan Martinez

 

 

 

 

 

 

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Walter R. Ojeda Valiente
Enviado el: Lunes, 13 de Septiembre de 2010 05:12 p.m.
Para: publice...@googlegroups.com
Asunto: RE: [vfp] Re: Lentitud en Select cuando la tabla esta abierta por dos usuarios

[IVAN MARTINEZ]

En general las dbf son mas rapidas que cualquier motor conocido siedmpre y cuando se manejen bajo la misma premisa.

 

Si con mysql solo accesas a un registro pues para hacer la comparacion debes hacer algo semejante en vfp.

Sino de que comparacion estamos hablando.

 

Es sabido que dada la rapidez de foxpro es que tiene tantos vicios de los cuales nos es dificil desprendernos.

 

Si a vfp lo manejas con SPT, con ado, con ole db, coin vistas remotas bien diseñadas los tiempos van aser semejantes.

 

Ahora como dijo Carlos Mata si abres una base de datos de 2 millones de registros en un form de facturacion encabezado , detalles y los relacionas con set relation sin ningun filtrado en el servidor esto va ha ser lentisimo , ya me paso.

 

En mi maquina volaba , pero cuando fui a la red real fue un desastre.

 

Es la forma de programar los accesos no el que sea dbf o no dbf. Esto hablando del tema de velocidad.

 

Ivan Martinez

 

 

 

 

 

 

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Walter R. Ojeda Valiente
Enviado el: Lunes, 13 de Septiembre de 2010 05:12 p.m.
Para: publice...@googlegroups.com
Asunto: RE: [vfp] Re: Lentitud en Select cuando la tabla esta abierta por dos usuarios

[Mario López]

@Luis Mata:

y bueno, ya que no te querés convencer, no uses DBFs.
Pero para que quede *bien* claro:

Tabla de más de 2 millones de registros con clave compuesta,
tamaño 1.6 Gby

USE T1Lect && Mi tabla de prueba
GO RECCOUNT()/2 && Voy a un registro en el medio de la tabla

sKey = KEY(1) && Obtengo la clave primaria
sEvKey = EVALUATE(sKey)
GO TOP

SYS(3054,12) && Para ver el nivel de optimización

* Actualizo algunos campos
UPDATE T1Lect SET LeProInf = 1, LeProSup = 100, LeEstact==5 WHERE
&sKey==sEvKey

Using index tag Remesa to rushmore optimize table t1lect
Rushmore optimization level for table t1lect: partial
Updated 1 record in 0,05 seconds
************ 0.05 segundos ************

* Borro un registro
DELETE FROM T1Lect WHERE &sKey==sEvKey

Using index tag Remesa to rushmore optimize table t1lect
Rushmore optimization level for table t1lect: partial
Deleted 1 record in 0,02 seconds
************ 0.02 segundos ************

>> Pseudo select, demasiado limitado ???

El hecho de "no saber" o "no querer" utilizar una característica no
quiere decir
que la misma no funcione.

Suerte,
Mario

[Luis Mata]

Para el nivel de trabajos que hago los dbf no me sirven, VPN, Via internet,
a mi no me funciono ,mientras sean locales quizas pero ya ya deje esa
arquitectura. seria descabellado hacer un sistema que interconecte
diferentes distritos del pais con los argumentos que uds me dan.
Si se sienten comodos trabajando con DBF adelante, pero los alcances son muy
limitados.
no me den pruebas que funcionan de una PC a otra en un ambiente local.

Luis Mata

----- Original Message -----
From: "Mario L�pez" <guag...@gmail.com>
To: "Comunidad de Visual Foxpro en Espa�ol"
<publice...@googlegroups.com>
Sent: Tuesday, September 14, 2010 7:47 AM
Subject: [vfp] Re: Lentitud en Select cuando la tabla esta abierta por dos
usuarios

@Luis Mata:

y bueno, ya que no te quer�s convencer, no uses DBFs.

Pero para que quede *bien* claro:

Tabla de m�s de 2 millones de registros con clave compuesta,
tama�o 1.6 Gby

USE T1Lect && Mi tabla de prueba
GO RECCOUNT()/2 && Voy a un registro en el medio de la tabla

sKey = KEY(1) && Obtengo la clave primaria
sEvKey = EVALUATE(sKey)
GO TOP

SYS(3054,12) && Para ver el nivel de optimizaci�n

* Actualizo algunos campos
UPDATE T1Lect SET LeProInf = 1, LeProSup = 100, LeEstact==5 WHERE
&sKey==sEvKey

Using index tag Remesa to rushmore optimize table t1lect
Rushmore optimization level for table t1lect: partial
Updated 1 record in 0,05 seconds
************ 0.05 segundos ************

* Borro un registro
DELETE FROM T1Lect WHERE &sKey==sEvKey

Using index tag Remesa to rushmore optimize table t1lect
Rushmore optimization level for table t1lect: partial
Deleted 1 record in 0,02 seconds
************ 0.02 segundos ************

>> Pseudo select, demasiado limitado ???

El hecho de "no saber" o "no querer" utilizar una caracter�stica no

[Victor Espina]

Luis, pero el escenario de un sistema distribuido en WAN es MUY
DISTINTO a uno en LAN. Los DBFs son perfectamente usables y
extremadamente rapidos en un ambiente LAN, siempre tomando en cuenta
problemas como la corrupcion de indices. Pero pretender abrir un DBF
a traves de una red que utiliza internet como medio de transporte es
simplemente imposible. Para esos escenarios es necesario una
arquitectura cliente/servidor como bien dices, pero ya estariamos
hablando de otra cosa distinta al escenario planteado originalmente en
la pregunta.

Victor Espina

[IVAN MARTINEZ]

 

Gracias

Ivan Martinez von Halle

---

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Humberto Díaz
Enviado el: Jueves, 09 de Diciembre de 2010 03:34 a.m.
Para: publice...@googlegroups.com
Asunto: [vfp] para los foxeros venezolanos

Sintiendo mucho lo ocurrido al avion venezolano accidentado

__________ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 5441 (20100910) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com

[Angel Ferreira]

Saludos a todos,

En primer lugar muchas gracias por responder y hacer de este tema un debate.  Estuve fuera unos dias y por eso no habia dado respuesta.

No pense que esta pregunta generaria una discucion de este tipo,  en realidad no era la intencion. 

Voy a realizar unas pruebas con Victor Espina y del resultado de las mismas les estaremos informando sobre la solucion al problema.

Lo que si debe quedar claro, es que la alternativa o sugerencia de migrar a SQL por esta problematica no es facil.

Decir que las DBF no funcionan y que la unica solucion a esa problematica es cambiar inmediatamente a SQL no es una respuesta que ayude mucho a resolver un problema de un cliente que tiene una aplicacion de varios anios funcionando,  tampoco es algo que se realice de la noche a la manana.  Todos sabemos que se necesita de mucho codigo para cambiar una aplicacion que corre con DBF hacia VFP si desde un principio no se tomo en cuenta este tipo de migracion.

Es verdad que la intencion es ir hacia SQL lo mas rapido posible,  pero eso lleva tiempo y esfuerzo en hacerlo,  adicional al costo que representaria para el cliente.

Ante esta situacion,  si la conclucion es que VFP no funciona bien con muchos registros (Cosa que no es asi,  lo digo por propia experiencia),  en este momento resolver el problema que planteo,  mas que migrar a SQL,  se basaria en una rutina que de alguna manera cree u optimize la forma en como estoy extrayendo la informacion de la DBF.

Luego....con tiempo y planificacion,  entonces se realizaria el cambio hacia SQL,  que por lo que he investigado no es para nada sencillo al momento de mirar el codigo Linea por Linea de un sistema Comercial que se encuentra operativo y funcional...

Seguimos tras la pista de este hilo a fin de obtener una solucion a dicha situacion. 

Estoy casi 100% seguro que el problema no son las DBF,  debe haber algo en mi codigo o en el contexto que este afectando el desempeno de esta parte del sistema.

Saludos,
AF

[Mario López]

@Angel:

Releyendo el problema que mencionabas en tu post original
-que ya para esta altura nadie se acordaba del mismo :) -
yo probaría:

* Chequear que en todos los índices el IDXCOLLATE()
se corresponda con el "SET COLLATION". En algún caso
me pasó que en una prueba cambié el SET COLLATION y
después generé un índice, el mismo quedó marcado con
un collation incorrecto y a partir de ahí Rushmore no
lo pudo utilizar para ninguna optimización.

* Sacar el índice por DELETED (ver
http://fox.wikis.com/wc.dll?Wiki~NonDiscriminatingIndex
para discusiones al respecto)

* Ejecutar la consulta directamente sobre el servidor
para descartar problemas de dispositivos de red (switch,
placa de red, etc)

* Idem anterior pero sobre un disco local (no mapeado
vía NET USE o UNC) para descartar algún posible problema
con el redirector de Windows.

* SET OPTIMIZE OFF, para verificar si el problema es
de alguna etapa de la optimización Rushmore.
Sin la optimización, tarda lo mismo la consulta con un
usuario o varios concurrentes?

* Si para ese punto sigue teniendo problemas yo compararía
el resultado de hacer la consulta con y sin usuarios
concurrentes, utilizando algún utilitario tipo:

- FileMon de SysInternals (para ver la cantidad de bytes
insumidos por la consulta)
- Server Monitor del Windows 2003 para analizar otros
detalles de la consulta (ej memoria, etc) y buscar el
cuello de botella

HTH
Mario

----

[Yascar Antonio Morales Parra]

gracias por hermanarte
 
Yascar Morales

 

---

From: iva...@gmail.com
To: publice...@googlegroups.com
Subject: OT RE: [vfp] para los foxeros venezolanos
Date: Tue, 14 Sep 2010 10:20:27 -0430

[Visual FoxPro Nuevo]

Buenas tardes,

Seguimos con este caso.

Les comento que quizá no me explique completamente en el inicio del
Hilo o tal vez no fui muy específico.

Conversando con Victor Espina, el mismo me sugirió realizar algunas
pruebas y detallar un poco más lo que estaba ocurriendo especificando
el Contexto.

Bien, el programa que estoy ejecutando lee simplemente 2 tablas y la
información de las mismas se utiliza para armar unos Estados
Financieros de Contabilidad mejor conocidos como Profit And Loss
(P&L).

El que conoce de estos P&L debe saber la complejidad en cuanto a
Columnas, información, formato, detalle y valores estadísticos que
este tipo de informe contable requiere.

Adicional a lo anterior, ningún Contador quiere adoptar un modelo
preexistente, es decir, siempre quieren darle un toque personalizado
a estos P&L agregando o quitando alguna caracteriza.

Por tal motivo, lo que se me ocurrió en ese momento fue partir la
programación de dichos P&L apoyándome en Excel de la siguiente manera:

1. Los usuarios utilizan Ms Excel, para armar la plantilla de sus
P&L. En Excel pueden especificar el diseño, formato, celdas, tipo
de letra y realizar cálculos matemáticos para efectos de porcentajes,
etc… Adicionalmente pueden incluir gráficos.

En las celdas donde se requiere Información Contable que se extrae del
sistema (Tablas VFP), entonces ellos utilizan con la ayuda de unos
Formularios hechos en VBA y un DLL hecho en VFP, unas formulas que
encapsulan el tipo de información que se desea buscar en el sistema y
presentar en las celdas. Por ejemplo: SaldoAnterior(“Cuentas”)

2. Creación de un DLL en VFP para interactuar entre los formularios de
Excel y el Sistema. Aquí se presentan datos como: Plan de Cuentas,
Formulas, Valores estadísticos, etc…

3. Creación de un programa en VFP que realiza lo siguiente:

a. Abre la plantilla de Excel
b. La recorre para todos los libros desde la primera celda a la
ultima
c. Evalúa cada celda a fin de conseguir alguna fórmula que deba
valorarse y retornar los datos de las tablas de contabilidad  Aquí es
donde se pone lento el sistema.

Todo lo anterior funciona perfecto….!

De hecho funciona tan bien que solo hace un mes aproximadamente es que
se ha presentado el problema de lentitud.

El tiempo general de ejecución de cada formula, es de aproximadamente
unos 0,90 seg lo que hace que un reporte que tenga una plantilla de
Excel de unas 495 celdas se ejecute en aproximadamente unos 35
segundos. Nada mal tomando en cuenta todo lo que debe ejecutar VFP
para armar el P&L. Lo que trato de decir con esto (Por si es un dato
importante), es que la cantidad de Selects que se ejecutan contra las
tablas de VFP va a depender del numero de celdas de la plantilla y de
la cantidad de cuentas que se mandan a investigar en la formula.

Lo cierto del caso, es que todo funciona de maravilla si el único
usuario que toca las tablas es el que está ejecutando el P&L, si por
alguna causa, existe otro usuario en alguna otra pantalla del sistema
donde dichas tablas se toquen o si simplemente se hace un USE de la
misma desde la ventana de comandos de VFP, entonces una plantilla
como la explicada, pasa de los 35 Seg a 25 minutos en el mejor de los
tiempos.

Las pruebas que realice para hacer descarte (Incluso las volví a
realizar el día de ayer), fueron las siguientes:

1. Ejecución del P&L en el Server --> Funciono OK
2. Ejecución del P&L en el Server con un USE hecho en el mismo Server
(Abrir VFP y ejecutar el USE) --> Funciono OK
3. Desde otra estación de trabajo se abre la tabla y se ejecuta el P&L
desde el Server --> Lentitud presentada.

En vista de lo anterior, el día de ayer se procedió con lo siguiente:

1. Compramos un Switch de 4 puertos.
2. Hicimos 3 patch cord respetando la normativa.
3. Formateamos un equipo e instalamos Windows 2003 Server Service Pack
2.

Adicionalmente, haciendo caso a la sugerencia de Luis Maria,
intentamos actualizar los Parches para Windows 2003 server obteniendo
lo siguiente:

" -- Los equipos basados en Windows Server 2003 funcionan más
lentamente y dejan de responder después de ejecutarse durante varios
día --
http://support.microsoft.com/kb/821008/es

-- El rendimiento puede ser lento en un controlador principal de sitio
que ejecuta servicio de Message Queuing Server --
http://support.microsoft.com/kb/832716/es

-- Puede experimentar rendimiento lento por algunos programas en
Microsoft Windows Server 2003 --
http://support.microsoft.com/kb/831168/es "


OK, el primer link, no permite por ningún lado solicitar el Parche
ni tampoco bajarlo, simplemente hace mención a una página de soporte
de Microsoft, por lo tanto no se instalo.

El segundo parche no se pudo instalar en vista de que el Windows 2003
server que montamos esta en Español y este parche existe solo para el
idioma Ingles.

El tercer parche no pudo ser instalado, porque nos dice que el
Service Pack del Windows que tenemos es mayor al fixed y por lo tanto
debe tenerlo incluido.

Luego de lo anterior, hicimos una mini red con dos equipos (Windows
XP) y el Server.

En todos los casos, tanto local como desde otro equipo, el P&L se
comporto de manera correcta y optima, es decir, no fallaba.

Pensé que el problema estaba resuelto, sin embargo, para descartar,
conectamos al Switch un cable de la Red Principal del cliente a fin de
evaluar el comportameniento con la Red del Cliente, pero con los
datos en el Nuevo Servidor.

Cuando ejecutamos el P&L desde otro equipo de la Red, entonces se
presento el problema, es decir, llego la lentitud.

Para demostrar al cliente que el problema estaba en su red, decidimos
desconectar el cable que venía de la Red del cliente y realizar las
pruebas nuevamente solo con el Server Nuevo y los dos equipos, pero
para nuestra sorpresa, la falla que al inicio no se presentaba, esta
vez fallo bajo el mismo escenario inicial.

Luego de esto, tratando de aislar más el problema, decidimos
desconectar del Switch el equipo con Windows 2003 server y copiar los
datos hacia uno de los equipos.

Hicimos la prueba de rigor y nada, seguía la Lentitud…

Llegados a este punto y en vista de las múltiples pruebas, concluimos
lo siguiente:

1. No era el Windows 2003 server porque estaba ocurriendo solo en 2
equipos con XP.
2. No era la Red del cliente, porque estábamos en un Switch
totalmente nuevo y donde solo estaban los 2 equipos.
3. No era cableado ni Rushmore ni nada de lo anterior.

Solo quedaba pensar que era la aplicación y que se trataba de un error
intermitente.

En vista de esto, decidimos llevarnos el Swith con los Patch Cord y
los equipos para realizar otras pruebas fuera del cliente.

Esta mañana, montamos la misma infraestructura con la grandiosa
sorpresa de que NO fallo en casi 300 pruebas de ejecución del P&L.

Comenzamos a pensar en lo que podríamos estar haciendo diferente a las
pruebas ejecutadas en el cliente. Lo único que nos falto probar,
fue apagar el Swith en el momento en que se presento el error en el
cliente, por lo que podemos concluir, que existe algo en la Red del
cliente que esta ocasionando un colapso en el Swith.

La pregunta es: Como se puede medir y determinar esto? Y como podemos
llegar a demostrar la causa?

Please Help….!

Gracias y disculpen lo largo de la explicación…



On 14 sep, 18:51, Yascar Antonio Morales Parra

<ymorale...@hotmail.com> wrote:
> gracias por hermanarte
>
> Yascar Morales
>

> From: ivan...@gmail.com
> To: publice...@googlegroups.com
> Subject: OT RE: [vfp] para los foxeros venezolanos
> Date: Tue, 14 Sep 2010 10:20:27 -0430
>
> Gracias
> Ivan Martinez von Halle
>

[ibania blanco]

hagan algo loco, creen un nuevo archivo con otro nombre, digiten
nuevamente los nombres de los campos, no con copy to, no con array,
digiten o recreen el archivo vacio, pasen con un scan, no appen from,
de un archivo a otro y validen ciertos campos, como no pasar registros
en blanco, valores a cero, nosotros en la coca cola de mi pais, no
paso algo igual, era el encabezado el malo, en donde estan los nombres
de los campos.

[Jorge Méndez]

Hola!

> Seguimos con este caso.

> Comenzamos a pensar en lo que podríamos estar haciendo diferente a las
> pruebas ejecutadas en el cliente.

Parece que esto ya pasaba allá por el 2008.

http://www.foxite.com/archives/slow-access-to-dbf-on-network-0000203810.htm

Tampoco encontraron solución.

No pasa siempre. Yo tengo ese problema en algunas instalaciones y en
otras no. Sólo he podido reproducirlo en una ocasión, lo justo para
ver que el problema es real, lo intenté reproducir de nuevo más tarde
y no pude. Sólo he podido comprobar aquellas circunstancias de las
que
parece que NO depende.

- No depende de la versión de windows del servidor ni del cliente
- No depende de antivirus o firewalls
- No depende del hardware de red
- No depende del nº de registros
- No parece depender de fases lunares o conjunciones planetarias,
pero
esto aún está por probar :-/

Las malas lenguas dicen que podría tratarse de un "incentivo" de M$
para que la gente migre a SQL Server, pero ya se sabe que hay mucha
maledicencia por ahí... }:-)

Un saludito!
Jorge.

[Humberto Díaz]

Un grupo de curiosos se encuentra mirando pasar un entierro por una calle, entonces un hombre se acerca a una mujer y:

 

hombre- Quien es el muerto?

 

mujer-   No estoy segura, pero creo que es el que va en el ataud

__________ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 5472 (20100923) __________

[Victor Espina]

Bueno, para actualixar un poco la situacion sobre este problema, debo
decir que el problema persiste, pero la percepcion de cara al usuario
mejoro notablemebte.

El SELECT que causaba el problema estaba efectivamente depurado y
optimizado, tal como indico Angel, pero la forma en que se USABA ese
SELECT no era la mas apropiada. Aplicando unas tecnicas de cache y
evitando reprocesos, se logro bajar significativamente los tiempos de
ejecucion del proceso que estaba causando la incomodidad del cliente.

Tambien Angel me confirmo que el problema se venia presentando desde
el servidor anterior, que no era Win 2003, solo que a medida que la
data en las tablas fue creciendo el problema se fue agudizando.

El articulo al que hace referencia Jorge concluye en que el tiempo de
respuesta LENTO deberia ser el correcto tanto para un solo usuario
como para dos o mas concurrentes. La razon de porque no es asi es
debido a una tecnica de bloqueo optimistico en recursos compartidos
que aplica Windows por defecto. Al desactivar esa opcion, mediante un
cambio en el Register, no se lograr mejorar los tiempos de respuestas,
sino UNIFICARLOs, de modo que sean lentos SIEMPRE, sin importar la
cantidad de usuarios concurrentes.

Creo que eso aclara el misterio, aunque no de la manera que
esperabamos.


Saludos

Victor Espina

On 24 sep, 05:21, Jorge Méndez <tope...@gmail.com> wrote:
> Hola!
>
> > Seguimos con este caso.
> > Comenzamos a pensar en lo que podríamos estar haciendo diferente a las
> > pruebas ejecutadas en el cliente.
>
> Parece que esto ya pasaba allá por el 2008.
>

> http://www.foxite.com/archives/slow-access-to-dbf-on-network-00002038...

[Carlos Miguel FARIAS]

menos mal!!!

2010/9/24 Humberto Díaz <humb...@ctc.cu>

[Angel Ferreira]

Gracias Victor por aclarar la situacion...

Como bien apuntas,  a pesar de resolver el inconveniente debido al recurrente uso de un Select que perfectamente podria evitarse y asi mejorar los tiempos de respuesta,  el problema original persiste por lo que seria interesante determinar su causa y solucion...

Gracias a todos por colaborar,  especialmente a Victor Espina quien participo de lleno en la revision y depuracion del programa...les comento que de 15 min bajamos la ejecucion del mismo a un minuto aproximadamente :)

Saludos,
AF

[Victor Espina]

Encontre informacion adicional sobre este tema. Definitivamente esta
relacionado con el OptimisticLocking que aplica Windows en algunas de
sus versions:

http://fox.wikis.com/wc.dll?Wiki~OpportunisticLocking~VFP
http://fox.wikis.com/wc.dll?Wiki~VisualFoxProOnWindowsServer2008~VFP

La conclusion final que saco al final de este tema es que la unica
forma de evitar a diferencia de rendimiento al acceder a un DBF
compartido luego de abrirlo en dos o mas PCs de la red, es desactivar
el OptimisticLocking del servidor, lo cual llevara a que el tiempo de
respuesta se estandarize pero hacia ARRIBA, es decir, tardara mucho
para todos los casos en lugar de solo para el 2do usuario en adelante.

Soluciones:
a) Optimizar al maximo los accesos a la BD y reducir al minimo dichos
accesos
b) Migrar su sistema de modo que use un motor de base de datos cliente-
servidor.


Saludos

Victor Espina

On 26 sep, 18:05, Angel Ferreira <angel...@gmail.com> wrote:
> Gracias Victor por aclarar la situacion...
>
> Como bien apuntas,  a pesar de resolver el inconveniente debido al
> recurrente uso de un Select que perfectamente podria evitarse y asi mejorar
> los tiempos de respuesta,  el problema original persiste por lo que seria
> interesante determinar su causa y solucion...
>
> Gracias a todos por colaborar,  especialmente a Victor Espina quien
> participo de lleno en la revision y depuracion del programa...les comento
> que de 15 min bajamos la ejecucion del mismo a un minuto aproximadamente :)
>
> Saludos,
> AF
>

[extremo]

el punto B lo considero mas una sugerencia que una solucion

Bendiciones

[Luis Mata]

?Asi es pero eso te lleva a tener una solucion excelente.

Luis

-----Original Message-----
From: extremo
Sent: Tuesday, September 28, 2010 11:20 AM
To: Comunidad de Visual Foxpro en Espa�ol
Subject: [vfp] Re: Lentitud en Select cuando la tabla esta abierta por dos
usuarios