Yo mismo en su momento me enfrenté con el mismo dilema. Descarté las vistas remotas porque dependen de una conección ODBC (que alguien me corrija si no estoy en lo cierto) y de una base de datos VFP y uno de mis requerimientos era que todo lo concerniente a datos debia almacenarse dentro del servidor (SQL Server), excepto alguna que otra metadata.

El CA también lo descarté por las mismas razones que tu expones, a veces es demasiado codigo solamente para tratar de actualizar una tabla, el límite de 255 caracteres (aunque hay un utilitario que resuelve este problema), etc.

SPT ni siquiera lo consideré también debido a que no quería tener nada que ver con conecciones ODBC.

Escogí una opción que no está entre las que propones y fue utilizar ADO como método de acceso a los datos. Con este método hasta ahora mi única dificultad fue pasar los datos del Recordset a un cursor VFP y viceversa, algo que se solucionó (más o menos) con el utilitario VFPCOM cuyo único problema, a su vez, es que no puede convertir recordsets que no contengan ningún registro a cursor VFP. Creeme! Poder pasar los datos de una forma a otra como un objeto es bastante divertido :)

Enmanuel

>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