[APP] eMans Administrador Corporativo para SQL2000/2005/MSDE - Beta 2 GRATIS/FREE

04/03/2005 - 14:11 por Gustavo Larriera [MVP] | Informe spam
http://www.emans.com/eMansAC/presen...allas.html

... escrito en Visual FoxPro (un MVP amigo del autor me pidió que
destacara que estaba programado en VFP :-))

Gustavo Larriera, MVP
Uruguay LatAm
http://sqljunkies.com/weblog/gux/
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and
confers no rights.

Preguntas similare

Leer las respuestas

#6 Pablo Roca
05/03/2005 - 02:42 | Informe spam
Suscribo todo lo que dice Jose Luis.

Creo que el problema viene originado de un mal diseño. VFP soporta sin
problemas decenas de usuarios y tablas con millones de registros.

Y tambien de acuerdo que esté fuera de .NET, solo quisiera que estuviera
dentro de los $ que tiene el equipo de .NET ... :))

Meter a VFP dentro de .NET le haría perder ciertas caracteristicas que
muchos desarrolladores de VFP no estan por la labor de perder.

Sin animo de polemizar ... llevo ya tiempo intentando que alguien me
justifique desde el punto de vista tecnologico la conveniencia de pasar las
aplicaciones de escritorio (no internet) a .NET y todavía no encontré ni un
solo argumento medianamente razonable. ¿Será posible que no lo hay?

La comunidad de VFP ... para mi chapó, un diez.

Y el trabajo de Antonio un once .. :))

Saludos,

Pablo Roca - Microsoft Visual Foxpro MVP
Sysop de PortalFox (http://www.portalfox.com)
La Coruña, España
"Apoya a FoxPro, utiliza software legal"
Respuesta Responder a este mensaje
#7 MAXI
05/03/2005 - 14:50 | Informe spam
Hola, bueno, yo te puedo dar algunas razones para pasar a .NET en escritorio

1) Mayor estabilidad de las aplicaciones
2) Mayor escalailidad a todo nivel
3) Menores costos de ROI
4) Si usas capas es solo un detalle
5) Olvidarte del infierno de las dll, donde hay veces que consume mucho
tiempo de verdad (este ha sido uno de los grandes factores por el cual
decidimos migrar a .net)
6) Preparar el escenario para los proximos años ya que en unos años
conseguir desarrolladores no .NET sera toda una asaña y ademas implicara un
costo adicional
7) El soporte, hasta cuando tendremos soporte para versiones viejas como
vb6?

Como veras hay varias razones





Maxi
Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)



"Pablo Roca" escribió en el mensaje
news:
Suscribo todo lo que dice Jose Luis.

Creo que el problema viene originado de un mal diseño. VFP soporta sin
problemas decenas de usuarios y tablas con millones de registros.

Y tambien de acuerdo que esté fuera de .NET, solo quisiera que estuviera
dentro de los $ que tiene el equipo de .NET ... :))

Meter a VFP dentro de .NET le haría perder ciertas caracteristicas que
muchos desarrolladores de VFP no estan por la labor de perder.

Sin animo de polemizar ... llevo ya tiempo intentando que alguien me
justifique desde el punto de vista tecnologico la conveniencia de pasar
las aplicaciones de escritorio (no internet) a .NET y todavía no encontré
ni un solo argumento medianamente razonable. ¿Será posible que no lo hay?

La comunidad de VFP ... para mi chapó, un diez.

Y el trabajo de Antonio un once .. :))

Saludos,

Pablo Roca - Microsoft Visual Foxpro MVP
Sysop de PortalFox (http://www.portalfox.com)
La Coruña, España
"Apoya a FoxPro, utiliza software legal"
Respuesta Responder a este mensaje
#8 José Luis Santana Blasco
05/03/2005 - 17:41 | Informe spam
"MAXI" escribió en el mensaje
news:
Hola, bueno, yo te puedo dar algunas razones para pasar a .NET en
escritorio

1) Mayor estabilidad de las aplicaciones



¿Es VFP inestable? Creo que es muy subjetiva tu apreciación.
¿Es .NET estable? Bueno, no puedo hablar mucho, pero he tenido grandes
"petardazos" de aplicaciones .NET.

No tengo datos para valorar cual es más estable, pero simplemente por
lógica, VFP es un producto maduro con más de 10 años en el mercado, y .NET
bueno, creo que me reconocerás, que aun está creciendo y estabilizandose.

2) Mayor escalailidad a todo nivel



Supongo que es escalabilidad.
Estamos hablando de aplicaciones de escritorio, por tanto debo suponer que
la escalabilidad la mides por la posibilidad de trabajar con grandes bases
de datos.
Dejemos a un lado que es un perfecto cliente de SQL Server.
Llevo muchos años trabajando con tablas dbf (si esas!!!) en tamaños de 500 a
800 Mb. sin grandes problemas de rendimiento.
Ten en cuenta, que si estas empleando SQL Server, estas empleando tecnología
VFP, por lo menos desde SQL server 7.

3) Menores costos de ROI



Aquí si te tengo que dar la razón. Si sabes VFP, sabes VFP y poco más
necesitas.

4) Si usas capas es solo un detalle



Te puedo decir, que la gente de VFP empleamos capas desde hace mucho tiempo,
gracias principalmente a que los gurus de VFP ya empleaban arquitectura de
capas y patrones desde hace bastante tiempo, y para los que llevamos tiempo
con VFP (en mi caso desde el 92) y nos preocupamos de estas al día de lo que
se cuece, esta gente es como la biblia. Mucha gente, especialmente de .NET
está conociendo ahora lo que son los patrones, o lo que es básicamente
arquitectura del software (los de java ya lo conocían). El primer artículo
de patrones aplicados a VFP data del 96, y yo lo leí en el 97.

Ten en cuenta que gente que te sonará del mundo .NET como:

Cathi Gero
Kevin McNeish
Markus Egger
Rick Strahl
Jim Duffy
Les Pinter
Ken Levy
Beth Massi
Yair Alan Griver (YAG)

Vienen del mundo VFP, y siempre se han preocupado de transmitir su técnica a
la comunidad (es la marca de la casa de la comunidad Fox), de hecho muchos
aspectos de la arquitectura de capas que lleva .NET, con la base de XML, ya
estaban presentes hace más de 6 años en el framwork COMCodeBook que YAG puso
a disposición de la comunidad.De hecho, el mismo YAG, responsable de bases
de datos de MS ya tenía un framework público desde 93 que se basaba en la
arquitectura de capas, hecho en VFP.

5) Olvidarte del infierno de las dll, donde hay veces que consume mucho
tiempo de verdad (este ha sido uno de los grandes factores por el cual
decidimos migrar a .net)



Principalmente la gente de VFP no sufre eso, la herramienta de desarrollo te
aporta casi todo lo que necesitas, no tienes que estar pensando en que OCX
emplear en cada momento.

6) Preparar el escenario para los proximos años ya que en unos años
conseguir desarrolladores no .NET sera toda una asaña y ademas implicara
un costo adicional



Aquí también te doy la razón. De hecho es la principal causa que nos estemos
planteando la migracio o sobretodo la convivencia de ambas plataformas en la
empresa que trabajo. Como bien se dice, cada herramienta para lo que es
buena, y VFP es aún muy buena para muchas cosas.

7) El soporte, hasta cuando tendremos soporte para versiones viejas como
vb6?



VFP9 hasta el 2014.

Pero tengo aún una aplicación en FoxPro para Dos funcionando, moviendo del
orden de 5 Gb. de información, y consultas a tablas de más de 500 Mb. sin
problemas. Y la verdad, para el soporte que siempre ha dado Microsoft en
España a la línea FoxPro, es lo que menos me preocupa, pues nunca me he
sentido arropado por ellos.


Como veras hay varias razones




Como veras muy pocas de las que me das me inclinan.

Te voy a dar yo una que es "el secreto mejor guardado de Microsoft".

VFP9 cuesta unos 600 Euros.
Una vez que lo has comprado, puedes hacer cientos y cientos de aplicaciones,
y tu única inversión, y la que debes repercutir a tus clientes por cada
aplicación que les instales es exactamente 0 Euros.
Una gran mayoria de aplicaciones de sobremesa que puedes hacer con SQL
Server, se podría hacer con VFP con un rendimiento similar, no por que VFP
sea igual de potente que SQL server, en ningun momento se me ocurriría decir
eso, estaría comparando dos cosas distintas, y SQL Server es un verdadero
gestor de base de datos a años luz de VFP, pero estarás conmigo, que en
muchos desarrollos donde se implanta SQL Server, se está empleando un 4% ó
5% de su potencia, eso no lo va a cambiar .NET, ni VFP, pero por lo menos
con VFP no le haces pagar a tu cliente por algo que no necesita.

Hay muchas cosas que no se pueden hacer con VFP, por lo menos facilmente,
ahí entra .NET, como antes entraba VB o C++, pero .NET solo ha hecho cambiar
el lenguaje, no ha inventado nada.

Yo estoy aprendiendo .NET, me gusta lo que estoy aprendiendo, pero eso no
cambia que siga pensando que una aplicación VFP puede ser mejor solución
para mis clientes, y sobre todo más rápida en según que situaciones. Todo
es, darle al cliente lo que le solucionará su problema ahora y en el futuro
de la forma más rápida y económica posible, y eso en muchos casos no pasa
por .NET, es más optimo VFP.

Espero no haberte molestado con mi mensaje, solo quería dar a conocer un
poco las posibilidades de VFP, no está en la misma liga de .NET.

No pretendo entrar en polemica, no vamos a ir a ningun sitio con ella, la
gente de VFP sabemos el producto que tenemos, y por lo menos yo reconozco
las bondades de .NET, pero también sé que no es la solución a todo, aunque
si a más cosas que VFP. Cada herramienta en su sitio.

Saludos.
José Luis Santana
Respuesta Responder a este mensaje
#9 Maxi
05/03/2005 - 23:58 | Informe spam
"José Luis Santana Blasco" escribió en el mensaje
news:%

"MAXI" escribió en el mensaje
news:
Hola, bueno, yo te puedo dar algunas razones para pasar a .NET en
escritorio

1) Mayor estabilidad de las aplicaciones



¿Es VFP inestable? Creo que es muy subjetiva tu apreciación.
¿Es .NET estable? Bueno, no puedo hablar mucho, pero he tenido grandes
"petardazos" de aplicaciones .NET.

No tengo datos para valorar cual es más estable, pero simplemente por
lógica, VFP es un producto maduro con más de 10 años en el mercado, y .NET
bueno, creo que me reconocerás, que aun está creciendo y estabilizandose.

2) Mayor escalailidad a todo nivel



Supongo que es escalabilidad.
Estamos hablando de aplicaciones de escritorio, por tanto debo suponer que
la escalabilidad la mides por la posibilidad de trabajar con grandes bases
de datos.
Dejemos a un lado que es un perfecto cliente de SQL Server.
Llevo muchos años trabajando con tablas dbf (si esas!!!) en tamaños de 500
a 800 Mb. sin grandes problemas de rendimiento.
Ten en cuenta, que si estas empleando SQL Server, estas empleando
tecnología VFP, por lo menos desde SQL server 7.

3) Menores costos de ROI



Aquí si te tengo que dar la razón. Si sabes VFP, sabes VFP y poco más
necesitas.

4) Si usas capas es solo un detalle



Te puedo decir, que la gente de VFP empleamos capas desde hace mucho
tiempo, gracias principalmente a que los gurus de VFP ya empleaban
arquitectura de capas y patrones desde hace bastante tiempo, y para los
que llevamos tiempo con VFP (en mi caso desde el 92) y nos preocupamos de
estas al día de lo que se cuece, esta gente es como la biblia. Mucha
gente, especialmente de .NET está conociendo ahora lo que son los
patrones, o lo que es básicamente arquitectura del software (los de java
ya lo conocían). El primer artículo de patrones aplicados a VFP data del
96, y yo lo leí en el 97.

Ten en cuenta que gente que te sonará del mundo .NET como:

Cathi Gero
Kevin McNeish
Markus Egger
Rick Strahl
Jim Duffy
Les Pinter
Ken Levy
Beth Massi
Yair Alan Griver (YAG)

Vienen del mundo VFP, y siempre se han preocupado de transmitir su técnica
a la comunidad (es la marca de la casa de la comunidad Fox), de hecho
muchos aspectos de la arquitectura de capas que lleva .NET, con la base de
XML, ya estaban presentes hace más de 6 años en el framwork COMCodeBook
que YAG puso a disposición de la comunidad.De hecho, el mismo YAG,
responsable de bases de datos de MS ya tenía un framework público desde 93
que se basaba en la arquitectura de capas, hecho en VFP.

5) Olvidarte del infierno de las dll, donde hay veces que consume mucho
tiempo de verdad (este ha sido uno de los grandes factores por el cual
decidimos migrar a .net)



Principalmente la gente de VFP no sufre eso, la herramienta de desarrollo
te aporta casi todo lo que necesitas, no tienes que estar pensando en que
OCX emplear en cada momento.

6) Preparar el escenario para los proximos años ya que en unos años
conseguir desarrolladores no .NET sera toda una asaña y ademas implicara
un costo adicional



Aquí también te doy la razón. De hecho es la principal causa que nos
estemos planteando la migracio o sobretodo la convivencia de ambas
plataformas en la empresa que trabajo. Como bien se dice, cada herramienta
para lo que es buena, y VFP es aún muy buena para muchas cosas.

7) El soporte, hasta cuando tendremos soporte para versiones viejas como
vb6?



VFP9 hasta el 2014.

Pero tengo aún una aplicación en FoxPro para Dos funcionando, moviendo del
orden de 5 Gb. de información, y consultas a tablas de más de 500 Mb. sin
problemas. Y la verdad, para el soporte que siempre ha dado Microsoft en
España a la línea FoxPro, es lo que menos me preocupa, pues nunca me he
sentido arropado por ellos.


Como veras hay varias razones




Como veras muy pocas de las que me das me inclinan.

Te voy a dar yo una que es "el secreto mejor guardado de Microsoft".

VFP9 cuesta unos 600 Euros.
Una vez que lo has comprado, puedes hacer cientos y cientos de
aplicaciones, y tu única inversión, y la que debes repercutir a tus
clientes por cada aplicación que les instales es exactamente 0 Euros.
Una gran mayoria de aplicaciones de sobremesa que puedes hacer con SQL
Server, se podría hacer con VFP con un rendimiento similar, no por que VFP
sea igual de potente que SQL server, en ningun momento se me ocurriría
decir eso, estaría comparando dos cosas distintas, y SQL Server es un
verdadero gestor de base de datos a años luz de VFP, pero estarás conmigo,
que en muchos desarrollos donde se implanta SQL Server, se está empleando
un 4% ó 5% de su potencia, eso no lo va a cambiar .NET, ni VFP, pero por
lo menos con VFP no le haces pagar a tu cliente por algo que no necesita.

Hay muchas cosas que no se pueden hacer con VFP, por lo menos facilmente,
ahí entra .NET, como antes entraba VB o C++, pero .NET solo ha hecho
cambiar el lenguaje, no ha inventado nada.

Yo estoy aprendiendo .NET, me gusta lo que estoy aprendiendo, pero eso no
cambia que siga pensando que una aplicación VFP puede ser mejor solución
para mis clientes, y sobre todo más rápida en según que situaciones. Todo
es, darle al cliente lo que le solucionará su problema ahora y en el
futuro de la forma más rápida y económica posible, y eso en muchos casos
no pasa por .NET, es más optimo VFP.

Espero no haberte molestado con mi mensaje, solo quería dar a conocer un
poco las posibilidades de VFP, no está en la misma liga de .NET.

No pretendo entrar en polemica, no vamos a ir a ningun sitio con ella, la
gente de VFP sabemos el producto que tenemos, y por lo menos yo reconozco
las bondades de .NET, pero también sé que no es la solución a todo, aunque
si a más cosas que VFP. Cada herramienta en su sitio.

Saludos.
José Luis Santana

Respuesta Responder a este mensaje
#10 Maxi
06/03/2005 - 00:05 | Informe spam
Hola Jose, mira creo que no tiene sentido responder semejante mail porque
estamos en un foro que es de sqlserver y no de programacion ;), de todas
maneras quiero hacer un comentario desde mi ignorancia

La empresa mas grande del mundo a nivel software (MS) tiene varios
productos, entre ellos varios en programacion. Desde hace unos añois esta
empresa hace mucha fuerza y pone todos sus cañones a .NET con lo cual como
yo soy un convencido de lo que hace MS y desde que trabajo en informatica y
he siguido sus lineas he ganado mucho dinero en el presente y tambien he
asegurado el del futuro, es que apunto por .NET, no quiero contarte todos
los beneficios tecnicos que tiene porque te estaria dando una ventaja
competitiva muy grande. Otro indicador es que esta misma empresa MS que
compro VFP hace unos años, ha querido sacarlo del mercado, esto no ha sido
posible gracias al enorme esfuerzo del grupo de usuarios de Fox, lo que no
quita que MS intente con su objetivo en unos años mas, por algo VFP no se
integra a.NET que es la plataforma en la que pone todos sus esfuerzos.

Con esto no quiero decir que no se programe en VFP ni mucho menos, cada cual
sabe en que herramienta debe programar, aun hay programadores Cobol y estan
muy contentos en lo que hacen, y esto creo que no es discutible para nada,
si VFP te es una herramienta util, pues utilizala y ya, no pienses que
necesito convencerte de no hacerlo y mucho menos de usar .NET, esa no es mi
funcion, tampoco debo convencer al mundo que use windows y no Linux, pero si
hay un detalle, el 90% usa Windows :-)

Un abrazo y cuando tengas una duda de SqlServer estere muy agradecido en
ayudarte


"José Luis Santana Blasco" escribió en el mensaje
news:%

"MAXI" escribió en el mensaje
news:
Hola, bueno, yo te puedo dar algunas razones para pasar a .NET en
escritorio

1) Mayor estabilidad de las aplicaciones



¿Es VFP inestable? Creo que es muy subjetiva tu apreciación.
¿Es .NET estable? Bueno, no puedo hablar mucho, pero he tenido grandes
"petardazos" de aplicaciones .NET.

No tengo datos para valorar cual es más estable, pero simplemente por
lógica, VFP es un producto maduro con más de 10 años en el mercado, y .NET
bueno, creo que me reconocerás, que aun está creciendo y estabilizandose.

2) Mayor escalailidad a todo nivel



Supongo que es escalabilidad.
Estamos hablando de aplicaciones de escritorio, por tanto debo suponer que
la escalabilidad la mides por la posibilidad de trabajar con grandes bases
de datos.
Dejemos a un lado que es un perfecto cliente de SQL Server.
Llevo muchos años trabajando con tablas dbf (si esas!!!) en tamaños de 500
a 800 Mb. sin grandes problemas de rendimiento.
Ten en cuenta, que si estas empleando SQL Server, estas empleando
tecnología VFP, por lo menos desde SQL server 7.

3) Menores costos de ROI



Aquí si te tengo que dar la razón. Si sabes VFP, sabes VFP y poco más
necesitas.

4) Si usas capas es solo un detalle



Te puedo decir, que la gente de VFP empleamos capas desde hace mucho
tiempo, gracias principalmente a que los gurus de VFP ya empleaban
arquitectura de capas y patrones desde hace bastante tiempo, y para los
que llevamos tiempo con VFP (en mi caso desde el 92) y nos preocupamos de
estas al día de lo que se cuece, esta gente es como la biblia. Mucha
gente, especialmente de .NET está conociendo ahora lo que son los
patrones, o lo que es básicamente arquitectura del software (los de java
ya lo conocían). El primer artículo de patrones aplicados a VFP data del
96, y yo lo leí en el 97.

Ten en cuenta que gente que te sonará del mundo .NET como:

Cathi Gero
Kevin McNeish
Markus Egger
Rick Strahl
Jim Duffy
Les Pinter
Ken Levy
Beth Massi
Yair Alan Griver (YAG)

Vienen del mundo VFP, y siempre se han preocupado de transmitir su técnica
a la comunidad (es la marca de la casa de la comunidad Fox), de hecho
muchos aspectos de la arquitectura de capas que lleva .NET, con la base de
XML, ya estaban presentes hace más de 6 años en el framwork COMCodeBook
que YAG puso a disposición de la comunidad.De hecho, el mismo YAG,
responsable de bases de datos de MS ya tenía un framework público desde 93
que se basaba en la arquitectura de capas, hecho en VFP.

5) Olvidarte del infierno de las dll, donde hay veces que consume mucho
tiempo de verdad (este ha sido uno de los grandes factores por el cual
decidimos migrar a .net)



Principalmente la gente de VFP no sufre eso, la herramienta de desarrollo
te aporta casi todo lo que necesitas, no tienes que estar pensando en que
OCX emplear en cada momento.

6) Preparar el escenario para los proximos años ya que en unos años
conseguir desarrolladores no .NET sera toda una asaña y ademas implicara
un costo adicional



Aquí también te doy la razón. De hecho es la principal causa que nos
estemos planteando la migracio o sobretodo la convivencia de ambas
plataformas en la empresa que trabajo. Como bien se dice, cada herramienta
para lo que es buena, y VFP es aún muy buena para muchas cosas.

7) El soporte, hasta cuando tendremos soporte para versiones viejas como
vb6?



VFP9 hasta el 2014.

Pero tengo aún una aplicación en FoxPro para Dos funcionando, moviendo del
orden de 5 Gb. de información, y consultas a tablas de más de 500 Mb. sin
problemas. Y la verdad, para el soporte que siempre ha dado Microsoft en
España a la línea FoxPro, es lo que menos me preocupa, pues nunca me he
sentido arropado por ellos.


Como veras hay varias razones




Como veras muy pocas de las que me das me inclinan.

Te voy a dar yo una que es "el secreto mejor guardado de Microsoft".

VFP9 cuesta unos 600 Euros.
Una vez que lo has comprado, puedes hacer cientos y cientos de
aplicaciones, y tu única inversión, y la que debes repercutir a tus
clientes por cada aplicación que les instales es exactamente 0 Euros.
Una gran mayoria de aplicaciones de sobremesa que puedes hacer con SQL
Server, se podría hacer con VFP con un rendimiento similar, no por que VFP
sea igual de potente que SQL server, en ningun momento se me ocurriría
decir eso, estaría comparando dos cosas distintas, y SQL Server es un
verdadero gestor de base de datos a años luz de VFP, pero estarás conmigo,
que en muchos desarrollos donde se implanta SQL Server, se está empleando
un 4% ó 5% de su potencia, eso no lo va a cambiar .NET, ni VFP, pero por
lo menos con VFP no le haces pagar a tu cliente por algo que no necesita.

Hay muchas cosas que no se pueden hacer con VFP, por lo menos facilmente,
ahí entra .NET, como antes entraba VB o C++, pero .NET solo ha hecho
cambiar el lenguaje, no ha inventado nada.

Yo estoy aprendiendo .NET, me gusta lo que estoy aprendiendo, pero eso no
cambia que siga pensando que una aplicación VFP puede ser mejor solución
para mis clientes, y sobre todo más rápida en según que situaciones. Todo
es, darle al cliente lo que le solucionará su problema ahora y en el
futuro de la forma más rápida y económica posible, y eso en muchos casos
no pasa por .NET, es más optimo VFP.

Espero no haberte molestado con mi mensaje, solo quería dar a conocer un
poco las posibilidades de VFP, no está en la misma liga de .NET.

No pretendo entrar en polemica, no vamos a ir a ningun sitio con ella, la
gente de VFP sabemos el producto que tenemos, y por lo menos yo reconozco
las bondades de .NET, pero también sé que no es la solución a todo, aunque
si a más cosas que VFP. Cada herramienta en su sitio.

Saludos.
José Luis Santana

Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida