Optimizar SQL2000

Hola, no quiero entrar en polemicas, pero que el Dataset es un ORM

Dije que "se basa" no que lo sea. ORM (object-relational mapping). Que
hace un DataSet si no mapear a objetos las tablas que le incluyamos (es
tambien un generador de código .NET, no mucho más, al menos hasta la
version 2005)? No es eso el concepto de un ORM?

Por supuesto que este no es el foro adecuado para discutir eso.

y tiene partes de Datawarehouse me parece que no estas bien informado.

Bueno, tal vez no use el termino correctamente por eso dije como un
"mini-DW" para hacer una imagen significando que un dataset lo lleno con
unos datos de distintas tablas relacionadas como una unidad integra que me
permita trabajar desconectado. Eso quise decir con lo de mini DW pero es
claro que no es exactamente un DW, si eso fue lo que entendiste.

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?

Sí.

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?

Sí. Y siempre ha sido así en VFP trabajando con SQL Server y lo que se
llama SQL PassThrough: abro conexion, lleno mi dataenvironment, cierro
conexion, actualizo, abro conexion, posteo las modificaciones y cierro
conexion. Mas general, eso se hace con cualquier lenguaje y el aporte de
.NET con sus datasets no es mas que autogenerar las clases que automaticen
un poco el proceso pero en el fondo sigue siendo lo mismo.

como lo desconozco pregunto porque siempre es bueno estar informado :-)

Eso es bueno. No lo sabemos todo y hay que preguntar.

Jose TH

Por opiniones como la suya manifestando algun nivel de ignorancia en el
tema es que muchos que usamos VFP salimos en su defensa. Y mira que no
soy el caso mas tipico porque programo actualmente mas en Delphi y C# que
en VFP, el cual conozco de hace solo unos 4 años.
Pero leyendo su opinion tan ligera sobre el tema puedo entender muy bien
por que los foxeros debemos opinar.


Jose TH



"Maxi" wrote in message
news:

Es verdad! la gente de VFP y los de Cobol son similes en esto,
francamente nunca lo entendi, yo programe en muchos lenguajes y nunca
defendi ninguno pareciera como que se aferran a uno y luego todo el resto
los ataca y que .net tiene cosas de fox y que lo desconectado lo usamos
en fox desde hace años, yo programe en Fox 2.6 y la verdad que tenia
muchas cosas de clipper, ahh eso si nunca escuche decir eso de la gente
de Fox ;) pero bueno son una comunidad "Especial" diria, hay que mimarlos
un poco ;-), yo hace años que deje de usar Fox y cualquier otro tipo de
lenguaje Xbase pero eso no quiere decir q sea malo ni mucho menos,
tampoco es el inventor de las cosas como muchos lo quieren hacer notar,
pero bueno!


Salu2

Microsoft MVP SQL Server
Culminis Speaker

"Lord Voldemort" escribió en el mensaje
news:e1$

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

ok, si entiendo eso. No dudo que a un maestro de SQL Server como lo eres
tu se le pasara algo asi. Solo me parecia que quien pregunto, pudiera
entender un poco mas especificamente su problematica.

saludos,

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


"Salvador Ramos" escribió en el
mensaje news:

Hola Antonio,

Mi intención no era comparar TS con una aplicación optimizada como tu
indicas.
Simplemente era proponer una alternativa sin costes de desarrollo y
sencilla de probar para comparar su funcionamiento, para ese caso en
concreto. Y en caso de que le vaya mejor que la configuración actual, que
la pueda implementar sin tener que rehacer la aplicación.

Un saludo
Salvador Ramos

www.helpdna.net (información sobre SQL Server y Microsoft .Net)
www.helpdna.net/acerca_de_salvador_ramos.htm


"Antonio Ortiz" escribió en el mensaje
news:

Asi es, supongo que se puede optimizar para que vaya mas rapido y las
imagenes esten de mas baja resolucion y se transfieran comprimidas. Aun
asi, mi apreciacion es que Terminal Server no es mejor solucion que una
aplicacion cliente-servidor bien diseñada, mas bien yo lo dejaria para
una aplicacion que No es cliente-servidor y se desea trabajar como tal
remotamente.

En mi experiencia con un sistema administrativo hecho en casa, con una
conexion a 50k, servidor PIII 800 mhz, 512 RAM, te devuelve un reporte
de ventas en 6 segs, a la vez que se usa el msn en el servidor. En aquel
entonces era posible incluso vender en caja conectado de este modo. Por
cierto el cliente era una aplicacion Access (.ADP).


saludos,

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





"Gustavo Larriera (MVP)"
escribió en el mensaje
news:

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
>
>

Gracias por tu sugerencia Gustavo, seria posible que me proporcionaras un
poco de info sobre como seria implementar una aplicación web. Aunque la
verdad meternos en el asunto de internet me da un poco de miedo por todo lo
de los virus, troyanos y demas. Pero si una aplicación web puede ser la
solucion creo que tendria que considerarlo.
Gracias nuevamente y te mando un saludo.
José Camacho Vaca
Colima, MX


"Gustavo Larriera (MVP)" wrote:

> 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

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