Javier, por lo que entiendo creo que estamos hablando de lo mismo.
Personalmente uso muchisimo VFP para el tratamiento local de datos luego de recuperarlos de una B.D remota (o directamente de un DBC).
La duda venia por el lado del tratamiento client/server y pasar a trabajar n-capas y abandonar la programación monolítica.

El hecho de que VFP tenga una sintaxis y funciones extremandamente utiles para el manejo de datos, asi como contar con SQL en el propio lenguaje lo destaca del resto y sin duda la velocidad de su motor es muy buena.

Inclusive el punto (3), que tu comentas, estamos discutiendo eso mismo, con VFP logras aplicaciones muy rapidamente y si vas a tratar datos remotos con SPT o C.A. o ADO en arquitectura n-capas, por que no usar -por ejemplo- Hibernate en JAVA en vez de VFP ?

Con SPT, C.A. y ADO te alejas un poco de la escencia de FoxPro (que no se mal interprete) y en definitiva estas logrando el mismo resultado que con otras herramientas y con un tiempo de desarrollo casi igual.

En el tema de los tiempos de desarrollo creo que depende mas de la habilidad y conocimiento del programador sobre la herramienta que de las propias caracteristicas de la misma. Tengo la suerte de trabajar con equipos de programadores "multi-lenguaje" y los veo resolver el tratamiento de los datos con una velocidad increible. El grupo de JAVA, los de ASP + SQL Server y el grupo de PHP con mySQL resuelven casi (o igual) tiempo que el grupo de VFP.

>Ricardo, yo creo que a veces se subestima el hecho de que VFP tenga un motor de datos propio. Aunque tengas todos tus datos en MS-SQL, Oracle, ..., tarde o temprano vas a recuperar un set de datos y trabajar con ellos en forma local, bien sea para obtener un resultado y ofrecérselo al usuario, o para tratar los datos y devolver al servidor éstos actualizados.
>
>El pensar que una aplicación simplemente "recupera datos del servidor, los muestra al usuario, éste los modifica, y la aplicación actualiza el servidor con los nuevos datos" creo que es ser un poco ingenuo. Al menos en mi caso hago mucho trabajo de tratamiento de datos local para obtener resultados. Y en este sentido el poder contar con un motor de datos propio y tan rápido como el de VFP es una ventaja muy grande. No sólo por el motor de datos, sino también porque toda la sintaxis de VFP está muy orientada a datos, con lo que el manejo de éstos pequeños set de datos es muy fácil de traducir a código.
>
>Por estas razones sigo creyendo que VFP es una herramienta en la que puedes tener una aplicación lista en menos tiempo que con otras herramientas que no son específicas de datos.
>
>>3) Un amigo me comento: "Lo bonito de VFP es el manejo de los datos y las funcionalidades incorporadas en el lenguaje, por ejemplo con tres líneas de código se puede manejar un set de datos (DataEnvironment, Binding, APPEND, DELETE, TABLEUPDATE y TABLEREVERT) y ya tengo andando una aplicación básica local o remota".
>>En otro lenguaje, eso mismo me lleva mucho código. Eso sí, si voy a usar S.P.T. o C.A. y voy a trabajar n-capas, por que hacerlo en VFP y no en otro lenguaje (por ejemplo Hibernate Framework con JAVA) si al fin y al cabo voy a usar los mismos recursos ?
>>
>>Saludos a todos.