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

Bueno aqui tienes un link, por si aca yo trabajo con visual basic
http://www.solotuweb.com/vc~t~socket-APIllamadas-API-en-VB~id~8995.html,
puedes utilizar la api como en el liink o puedes utilizar el control sockets
o winsock que viene con visual basic, supongo que en visual fox tambien debe
de haber. Aqui tienes un ejemplo
http://www.monografias.com/trabajos...tuto.shtml con winsock

Saludos


"Jose Camacho Vaca" escribió en
el mensaje news:

Perdon, y abusando de tu amabilidad, pero no seria posible que me pasaras
algo de info sobre sockets, no los he manejado nunca. Gracias por tu
ayuda.
Saludos.
José Camacho Vaca
Colima, MX


"jcac" wrote:

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

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

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