Hola, Enmanuel.

>>Bueno, no es estrictamente necesaria una DBC para usar una vista remota. Puede hacerse por completo por código. Si es cierto que trabajan por ODBC.
>>
>
>No sabía que se podía tener una vista remota "on the fly" si a eso es que te refieres.

Básicamente, usas SQL-Pass through y con DBSetProp indicas las características de actualización y ya. De hecho el editor de Vistas desde VFP 8, si miras el SQL generado, te muestra todos los DBSet...

>>Cualquier método de acceso a datos requiere algo de código. El tema es que si te pones a crear un cursor adapter con todas sus propiedades cada vez, si es engorroso. si creas una ssubclase con todos tus defaults y simplificas la invocación, debería ser tan simple como cualquier otro método.
>>
>
>Cuando estaba probando el CA, diseñe una clase para DE y otra para CA pero había varias cosas que no lograba entender como por ejemplo que no pudiera utilizar instrucciones SELECT complejas, especialmente frustrante fue el límite de 255 caracteres en el SELECTCMD del CA.

No se que selects no te funcionaron el en CA que si lo hagan por ADO. Si me envías un ejemplo lo vemos. El tema del límite es del Builder, no del CA, como mencioné antes. Si lo escribes en código no tienes ningún límite.

>
>>No queda claro porque descartas las conexiones ODBC. ¿Era un requerimiento por alguna razón en particular?
>>
>
>Mi razón primordial fue el no querer tener que configurar un DSN en cada PC al momento de hacer la instalación (quizás sea algo de holgazanería <g>), prefiero el string de conección que es más fácil y puedo construirlo al momento de configurar la aplicación (aunque según investigué posteriormente esto también puede hacerse con ODBC).

Pues con utilizas SQLStringConnect() te alcanzaba. No hace falta generar DSNs individuales.

>>
>>Bueno, utilizando ADO manualmente y creando tus propias clases no deberías tener ninguna limitación.
>>
>
>Realmente hasta ahora no he tenido ninguna, ADO me ha proporcionado todo lo que he requerido para mis aplicaciones y mas; lo que más me gusta de ADO es la posibilidad de manejar stream de datos o sea procedimientos almacenados que retornen más un recordset.

Esto también puedes hacerlo por ODBC. Con esto no quiero decir que ODBC sea mejor que ADO, ni mucho menos (cada uno tiene sus falencias), sino que muchas de las razones que se esgrimen para no usar una u otra metodología a veces no están suficientemente fundadas. Estas son las condiciones que digo que te pueden llevar a decisiones erróneas si pretendes escribir un framework propio.

>Mis clases de acceso a los datos.
>
>CONECTAR - Se conecta al servidor
>
>GETRS - Envia una petición al servidor, puede ser el nombre de un SP o una instrucción select.
>
>RSTOCURSOR - pasa los datos de recordset a un cursor VFP (utilizando VFPCOM.DLL o manualmente)
>
>UPDATERS - Actualiza los datos y mediante parámetros indico si deseo iniciar o terminar una transacción (o ambas cosas a la vez).
>
>DESCONECTAR - El nombre lo dice todo
>
>Mi framework también consta de otras clases y métodos que complementan los anteriores pero mi punto es que se puede lograr una clase de acceso a datos sin mucho esfuerzo, claro todo depende de tus requerimientos.

Bueno, está muy bien, pero esto no es un framework ni mucho menos, sino una clase que empaqueta el acceso a datos, sin indicio de separación de capas ni nada más que acceso a datos en un servidor remoto, y atado a una implementación específica: ADO. Lo ideal sería que la interfaz de tu componente de acceso a datos te aisle por completo de la implementación.

Saludos,