Tanto SPT como las vistas remotas no son dependientes de DSNs si es que es a lo que te referías, ambas pueden utilizar cadenas de conexión del mismo modo como lo haces con ADO/OLEDB, por lo que puedes guardar su configuracion en alguna metadata, o usar la autentificacion de SQLServer/Windows.

--- Conectar a DBMS sin crear DSN (técnica DSNLess) ---
http://www.panoramabox.com/GoPub.aspx?IdObj=1205

http://fox.wikis.com/wc.dll?Wiki~DSNLessConnections

Si querias correción... Concedido ;-)

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 Visual FoxPro 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 ActiveX Data Objects 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 Visual FoxPro 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 Visual FoxPro. 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 Visual FoxPro 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 Visual FoxPro 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