>
>
>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.

>
>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 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).

>
>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.

>El tema, de nuevo, me parece que es tratar de escribir tu propio mecanismo de acceso a datos sin poder dedicarle el suficiente tiempo de estudio y desarrollo. Es por eso que recomiendo investigar un poco y utilizar soluciones ya construidas, al menos como herramienta de estudio para hacer tus versiones.
>

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.

Enmanuel