Optimizar SQL2000

No se que tan descabellada sea esta propuesta pero puedes trabajar con
sockets, pero tendrias que rearmar tus aplicaciones para qeu solo envien
textos, y un programa que escuche cada uno de estas cadenas y haga lo que tu
desees y te devuelva lo que desees tambien, ten en cuenta que solo envias
texto algo mas sencillo que inclusive este mensaje de noticia.

Saludos y suerte

"Jose Camacho Vaca" escribió en
el mensaje news:
> 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

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.

Las soluciones en general a este tipo de situaciones son: Rearquitecturizar
la aplicacion para que trabaje en modo desconectado (con sincronizaciones
esporádicas al servidor) o implementar una aplicación web para los usuarios
que acceden por conexión lenta.

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.



"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

Terminal Server usa el protocolo RDP, que está diseñado para trabajar en
redes de baja velocidad y Microsoft lo recomienda en tales escenarios.
Considerar que la conexion remota puede personalizarse para consumir el
minimo ancho de banda posible (desactivando sonido, bajando la resolucion
grafica, etc.)

Por detalles acerca del consumo de recursos y el rendimiento de RDP ver:

http://www.microsoft.com/technet/pr...fperf.mspx

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.



"Antonio Ortiz" wrote:

Y no seria mayor el 'trafico' de enviar pantallas a la pc remota?

saludos,

Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com



"Salvador Ramos" escribió en el
mensaje news:%
> Hola,
>
> Otra alternativa sería utilizar Terminal Server (u otro producto
> similar),
> con lo que todo ese tráfico se produciría en la LAN.
>
> Un saludo
> Salvador Ramos
>
> www.helpdna.net (información sobre SQL Server y Microsoft .Net)
> www.helpdna.net/acerca_de_salvador_ramos.htm
>
>
> "Jose Camacho Vaca"
> escribió
> en el mensaje
> news:
>> 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
>
>

jejejee
te has fijado en eso...
jajaja...
pues es cierto lo que dices...
no solamente en los news sino platicando tambien..
siempre se nota que estan a la defensiva..

No te compliques pasala bien


Lord Voldemort
Visual Basic 2005

Página de inicio del grupo: http://mx.groups.yahoo.com/group/vb2005Mysql
Dirección de correo del grupo:

"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

> 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