Optimizar SQL2000

07/08/2007 - 20:14 por Jose Camacho Vaca | Informe spam

Una consulta, por razones de presupuesto tenemos conexion muy lentas a
nuestro servidor SQL, hasta 3 maquinas enlazadas sobre una conexion de
64kbps. Obviamente todo eso nos esta perjudicando en la velocidad de nuestra
aplicación principal que es de tipo OnLine. Las características generales
del sistema y de la infraestructura son las siguientes: servidor HP Proliant
ML370 1Gb. RAM 3 DD SCSI de 40 Gb. (no estan en RAID),
SmallBussinessServer2003, SQL-Server2000, se conectan hasta 40 terminales
simultáneamente. Nuestra apliacion esta hecha en VFP8, usa SQLPassThroug
bastante optimizado, todos los equipos terminales tienen WinXP-Pro con 256 de
memoria. Los que se conectan a la red local por medio de cable no tienen
ningún problema, pero los que se conectan por medio de un enlace de linea
dedicada de 64 Kbps, se vuelven muy lentos.
Cualquier sugerencia será bien recibida, mucha gracias.
Saludos.
José Camacho Vaca
Colima, MX

Siga el debate

39 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#6 jmauriciopb

08/08/2007 - 00:03 | Informe spam

de acuerdo con principiante, desde hace ya tiempo trabajamos en forma
desconectada en VFP si Jose a optimizado la descarga de datos desde el
servidor ya no hay mas que hacer que mejorar el enlace.

Saludos,
Mauricio Pulla.
Cuenca-Ecuador.

On 7 ago, 16:05, "principiante" wrote:

.NET trae una clase dataset que está "prediseñada y pensada para un
escenario desconectado" porque se basa en un ORM y a la vez es como un
mini-datawarehouse pero que crees? en VFP hace tiempo que trabajamos en
escenarios desconectados C/S (siempre hemos podido) con ODBC, SQL Pass
Through y aprovechando la connection pooling implementado nuestro "dataset"
al estilo de VFP (dataenvironment). Y hasta más eficiente pues tenemos más
control de sólo traer lo necesario desde el principio (no digo que en .NET
no se pueda programar también).

Todo depende de cómo programes tu aplicación no importa el lenguaje de la
aplicación cliente.

Jose TH

"Maxi" escribió en el mensajenews:%239B7%

> Hola, en .net cambia la cosa porque trabajas en un ambiente desconectado
> con los Dataset

> Salu2

> Microsoft MVP SQL Server
> Culminis Speaker
>
> "principiante" escribió en el mensaje
>news:%
>>> No hay muchas posibilidades de mejorar siendo el cuello de botella una
>>> red
>>> lenta. Cuando la red es lenta, una solución basada en cliente grueso
>>> (como es
>>> el caso de VFP) es una mala solución.

>> Pero no porque sea VFP. Lo sería igual para cualquier Fat-client o para
>> cualquier aplicación windows típica de .NET.

>> Jose TH- Ocultar texto de la cita -

- Mostrar texto de la cita -

Responder a este mensaje

#7 Gustavo Larriera (MVP)

08/08/2007 - 00:30 | Informe spam

Cada vez que los de SQL Server mencionamos algo que parece una crítica a
VFP o a Access, la gente se pone algo susceptible :-)

En ningun momento dije que el problema es VFP sino que claramente dije
que el problema era usar una solución basada en cliente grueso, y
ejemplifiqué con VFP porque es lo que el amigo del problema dice tener.

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.Larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.

In article <#,
says...

> No hay muchas posibilidades de mejorar siendo el cuello de botella una red
> lenta. Cuando la red es lenta, una solución basada en cliente grueso (como
> es
> el caso de VFP) es una mala solución.
>

Pero no porque sea VFP. Lo sería igual para cualquier Fat-client o para
cualquier aplicación windows típica de .NET.

Jose TH

Responder a este mensaje

#8 Jose Camacho Vaca

08/08/2007 - 01:08 | Informe spam

Muchas gracias a todos por sus respuestas. Bueno, antes que nada, parece que
de manera definitiva voy a tener que migrar a otra arquitectura. Primero, el
volumen de datos no es tanto el problema, sino el trafico que hay en la red,
normalmente un proceso implica lo siguiente:
Dame el No. de cliente.
Dame el detalle de la cuenta del cliente.
Dame los abonos del renglón 5 del detalle.
Dame los documentos del primer abono
y volvemos al primer paso.
Lo malo como pueden ver es que hay mucho trafico de ida y vuelta, no es
mucho con lo que se trafica, pero si muchas veces y eso multiplicado por el
No. de equipos hace lenta la conexión.
Al parecer la solución va a ser ASP o algo por el estilo.
De todas formas cualquier sugerencia adicional va a ser bien recibida.
Gracias nuevamente y saludos.
José Camacho Vaca
Colima, MX

"Jose Camacho Vaca" wrote:

Una consulta, por razones de presupuesto tenemos conexion muy lentas a
nuestro servidor SQL, hasta 3 maquinas enlazadas sobre una conexion de
64kbps. Obviamente todo eso nos esta perjudicando en la velocidad de nuestra
aplicación principal que es de tipo OnLine. Las características generales
del sistema y de la infraestructura son las siguientes: servidor HP Proliant
ML370 1Gb. RAM 3 DD SCSI de 40 Gb. (no estan en RAID),
SmallBussinessServer2003, SQL-Server2000, se conectan hasta 40 terminales
simultáneamente. Nuestra apliacion esta hecha en VFP8, usa SQLPassThroug
bastante optimizado, todos los equipos terminales tienen WinXP-Pro con 256 de
memoria. Los que se conectan a la red local por medio de cable no tienen
ningún problema, pero los que se conectan por medio de un enlace de linea
dedicada de 64 Kbps, se vuelven muy lentos.
Cualquier sugerencia será bien recibida, mucha gracias.
Saludos.
José Camacho Vaca
Colima, MX

Responder a este mensaje

#9 principiante

08/08/2007 - 01:10 | Informe spam

Está bien, pero no lo vuelvas a hacer ;-)

Jose TH

"Gustavo Larriera (MVP)" escribió en el mensaje
news:
Cada vez que los de SQL Server mencionamos algo que parece una crítica a
VFP o a Access, la gente se pone algo susceptible :-)

En ningun momento dije que el problema es VFP sino que claramente dije
que el problema era usar una solución basada en cliente grueso, y
ejemplifiqué con VFP porque es lo que el amigo del problema dice tener.

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.Larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.

In article <#,
says...

> No hay muchas posibilidades de mejorar siendo el cuello de botella una
> red
> lenta. Cuando la red es lenta, una solución basada en cliente grueso
> (como
> es
> el caso de VFP) es una mala solución.
>

Pero no porque sea VFP. Lo sería igual para cualquier Fat-client o para
cualquier aplicación windows típica de .NET.

Jose TH

Responder a este mensaje

#10 Maxi

08/08/2007 - 15:09 | Informe spam

Hola, no quiero entrar en polemicas, pero que el Dataset es un ORM y tiene
partes de Datawarehouse me parece que no estas bien informado.
Para mi informacion porque realmente lo desconozco, cuando vos decis que
trabajas en VFP en un ambiente desconectado esto quiere decir que matas la
conexion y podes seguir moviendote sin problemas y que cuando haces un
cambio en el modelo desconectado luego los podes pasar cuando te conectas
sin la necesidad de estar conectado? o sea: te traes por ejemplo 10 clientes
y cerras la conexion, modificas 5 clientes y luego los guardas conectando y
pasando la data al SQL? como lo desconozco pregunto porque siempre es bueno
estar informado :-)

Salu2

Microsoft MVP SQL Server
Culminis Speaker

"principiante" escribió en el mensaje
news:

.NET trae una clase dataset que está "prediseñada y pensada para un
escenario desconectado" porque se basa en un ORM y a la vez es como un
mini-datawarehouse pero que crees? en VFP hace tiempo que trabajamos en
escenarios desconectados C/S (siempre hemos podido) con ODBC, SQL Pass
Through y aprovechando la connection pooling implementado nuestro
"dataset" al estilo de VFP (dataenvironment). Y hasta más eficiente pues
tenemos más control de sólo traer lo necesario desde el principio (no digo
que en .NET no se pueda programar también).

Todo depende de cómo programes tu aplicación no importa el lenguaje de la
aplicación cliente.

Jose TH

"Maxi" escribió en el mensaje
news:%239B7%

Hola, en .net cambia la cosa porque trabajas en un ambiente desconectado
con los Dataset

Salu2

Microsoft MVP SQL Server
Culminis Speaker

"principiante" escribió en el mensaje
news:%

No hay muchas posibilidades de mejorar siendo el cuello de botella una
red
lenta. Cuando la red es lenta, una solución basada en cliente grueso
(como es
el caso de VFP) es una mala solución.

Pero no porque sea VFP. Lo sería igual para cualquier Fat-client o para
cualquier aplicación windows típica de .NET.

Jose TH

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3 4 5 6 7 8

Busqueda sugerida