Hace unos días planteaba la inquietud de re-progrmar un sistema FoxPro 2.6 a VFP client/server y Plinio Fermin nos daba la sugerencia de crearnos nuestro propio FrameWork.

Luego de varios dias de discución optamos por esta opción.
Estamos creando nuestro propio FrameWork client/server basado en vistas remotas parametrizadas y SQL Pass Through (de uso interno y sin fines comerciales).
Tomamos como base el ejemplo de Tastrade que trae VFP y lo modificamos a origenes de datos remotos ademas de quitarle metodos innecesarios y agregarle los propios.

Un tema interesante que queria cometarles es que no estamos usamos la clase CursorAdapter ya que vimos en principio varios obstaculos:

- No soporta en forma nativa clausulas WHERE.
- Usar la propiedad .SelectCmd nos parece muy pesada y larga, ademas soporta hasta 255 caracteres y mucho 'coding'.
- El binding es mucho mas práctico con el DataEnvirnoment y vistas remotas.
- No pudimos usar comandos nativos de SQL
- Nos parecio que tenemos que escribir mucho mas codigo usando CursorAdapter con las propiedades .SelectCmd, .InsertCmd y .DeleteCmd por cada tabla que vamos a usar en un form que simplemente arrastar al DataEnvirnoment la vista remota.
- Con un método de conectividad lo suficientemente inteligente nos podemos aproximar bastante a una plataforma n-tier y alejarnos de la programación monolitica (estamos trabajando en eso).

Hay un articulo de Les Pinter muy bueno en base a trabajar en 3 capas que lo usamos como referencia:
http://www.mug.org.ar/FoxProGufa/ArticFox/210.aspx

Y hay una discución sobre CursorAdapter muy interesente en Wikis:
http://fox.wikis.com/wc.dll?Wiki~CursorAdapterOrNot~VFP

Mucho de estos problemas son fruto de nuestra ignorancia de no conocer la clase a fondo. Pero nos parecio interesante discutirlo y saber si alguien esta trabajando en algún proyecto similar y se topó con el dilema de usar Vistas Remotas, CursorAdapter o S.P.T. y cuales fueron sus razones para usar una u otra.

Saludos,
RFR