Lentitud en Select cuando la tabla esta abierta por dos usuarios

09/09/2010 - 17:50 por Visual FoxPro | Informe spam
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 10Seg 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 10Seg 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 (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.

Preguntas similare

Leer las respuestas

#1 marcelobuenosaires
10/09/2010 - 12:16 | Informe spam
Hola

El grupo se mudo a

Saludos
MarceloBuenosAires
____________

On 9 sep, 12:50, Visual FoxPro wrote:
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 10Seg 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 10Seg 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 (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.
Respuesta Responder a este mensaje
#2 Visual FoxPro
10/09/2010 - 23:40 | Informe spam
On 10 sep, 03:16, marcelobuenosaires
wrote:
Hola

El grupo se mudo a

Saludos
MarceloBuenosAires
____________

On 9 sep, 12:50, Visual FoxPro wrote:

> 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 10Seg 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 10Seg 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 (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.



Gracias marcelo!!!
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida