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.