Artículo escrito por Antonio Castaño, Microsoft Visual FoxPro - MVP y publicado en la revista del MUG (MS

Users Group de Argentina) en el mes de Junio de 2000.

ADO para desarrolladores Visual FoxPro

Por Antonio Castaño, da-Vinci - Innovación Tecnológica, Buenos Aires, Argentina

Nota de PortalFox:

Este artículo fue escrito por Antonio Castaño, Microsoft Visual FoxPro - MVP y publicado en la revista del
MUG (MS Users Group de Argentina) y publicado en el mes de Junio de 2000. Cabe aclarar que algunos
temas y vínculos pueden estar desactualizados.

Introducción

De todas las tecnologías que han surgido en los últimos tiempos, ADO es una de las más interesantes y una de
las que se utiliza en mayor cantidad de productos y herramientas de la familia Microsoft.

Y como se trata de una tecnología específica de acceso a datos, es de especial interés para los desarrolladores
Visual FoxPro.

El objetivo de este artículo es destacar algunos características de especial interés para quienes usamos Visual
FoxPro como principal herramienta, y comentar algunas particularidades de su uso. No se pretende en este corto
espacio, desarrollar todas las características y funcionalidades de ADO. Existe una gran cantidad de
documentación, artículos y libros sobre la materia, algunos de los cuales se mencionan en el título Referencias.

Algunas definiciones

La tecnología ADO (Active Data Objects) forma parte de la estrategia definida por Microsoft para acceso a
datos (UDA: Universal Data Access), que se implementa a través del sucesor de ODBC, OLE DB (más
información: http://www.microsoft.com/data).

ADO es un conjunto de clases que se instalan en cualquiera de las versiones de Windows de 32 bits, y sus
objetivos son:

 Proveer acceso a datos independientemente de su formato y/o ubicación

 Proveer una interfaz basada en objetos a OLE DB, a través de un modelo de objetos simple y flexible
 Que pueda ser usado desde cualquier lenguaje / entorno que permita trabaja con objetos COM/ActiveX

ADO y Visual FoxPro

En su versión actual, VFP no cuenta con mecanismos específicos de RAD (Rapid Application Developement)
para hacer uso de ADO, pero al ser ADO un conjunto de clases COM, pueden ser utilizado en su funcionalidad
completa sin ningún problema.

Si bien otras herramientas de Visual Studio (VB, VI) cuentan con algunos componentes RAD específicos para
hacer uso de la funcionalidad de ADO, los desarrolladores de cualquiera herramienta que deban encarar la tarea
de hacer código robusto y realmente reutilizable, deberán recurrir al uso programático de ADO, tal cual se hace
en Visual FoxPro.
Visual FoxPro tiene la natural características de ser una herramienta ideal para construir aplicaciones basadas en
componentes, gracias a su rica implementación de programación orientada a objetos (OOP).

Es por eso que para los desarrolladores VFP, ADO, al ser una tecnología basada en objetos, abre todo un mundo
de posibilidades. Uno de los fuertes de Visual FoxPro, dentro del espectro de herramientas de Visual Studio, es
el desarrollo de componentes de negocio en los que sea crítica la habilidad para obtener y manipular datos. La
posibilidad de utilizar esta tecnología para el intercambio de información entre estos componentes, ofrece
nuevas alternativas para implementar soluciones robustas y flexibles.

Por otra parte, cabe destacar que, al haber sido ADO desarrollado por integrantes del equipo que desarrolló
Visual FoxPro, con el objeto de aprovechar la excepcional tecnología de manejo de cursores que tiene VFP,
existen una cantidad de conceptos y hasta de terminología, que resultarán familiares.

Manos a la obra...

Para trabajar con ADO, es importante instalar el Service Pack 3 de Visual Studio. Este SP, además de
solucionar una lista importante de bugs, mejora los mecanismo para las comunicaciones a través de COM. Por
ejemplo, con la aplicación de este SP, VFP es un “mejor ciudadano” corriendo bajo MTS (Microsoft
Transaction Server), y permite construir multithreaded dlls. Otro de los efectos visibles de estas mejoras, es que
teniendo aplicado el SP3 es posible utilizar controles ActiveX que permitan su asociación (“boundeo”) a
recordsets de ADO (ej: Microsoft Hierarchical Flex Grid, o Protoview TreeViexX).

Otro componente que es conveniente instalar para trabajar con ADO, es una .dll que se publicó con
posterioridad a la salida de la versión 6, pero que no está incluida en el Service Pack 3. Se trate de
vfpcom.dll. Esta .dll, junto con la documentación de cómo usarla y algunos ejemplos, puede obtenerse en el
sitio de MS:
http://msdn.microsoft.com/vfoxpro/downloads/vfpcom.exe

Esta .dll es un COM Server e incluye una única clase, comutil, que tiene una serie de métodos que proveen dos
tipos de funcionalidades bien diferentes, pero que ambos pueden ser de utilidad cuando se trabaja con
ADO.

Por una parte, están los métodos RsToCursor y CursorToRs. Cómo su nombre hace suponer, estos métodos
permiten convertir RecordSets de ADO a cursores de VFP y viceversa. Ya existían unas funciones para realizar
estas tareas, desarrolladas por Ken Levy y puestas en el dominio público (pueden obtenerse en el sitio de Ken
en:
http://www.classx.com/), pero estas .dll realizan la conversión en forma mucho más eficiente. Es necesario
aclarar que esta .dll no es soportada por MS salvo en lo que hace a su instalación; dada las constantes
actualizaciones de ADO, existe alguna probabilidad de que con el tiempo aparezca algún tipo de
incompatibilidad. De hecho, nuestra experiencia es que hay ciertos tipos de datos en RecordSets ADO que la
.dll no soporta.

De todas maneras, como lo indican las buenas prácticas de programación, sea cual sea el mecanismo que se
utilice para hacer esta conversión, deberá estar convenientemente encapsulado y parametrizado para poder,
eventualmente, utilizar un método u otro.

El otro grupo de funcionalidades que provee la vfpcom.dll se refiere a la posibilidad de detectar eventos de
objetos COM. Esta funcionalidad no está presente en VFP 6 (si bien ya está anunciado que va a formar parte de
funcionalidad básica de VFP 7).

Una de las particularidades de ADO, es su capacidad de generar eventos. Esta .dll permite detectar la presencia
de esos eventos desde un aplicación VFP. Sin embargo, la utilidad de estos métodos, va mucho más allá del uso
de ADO. Permitiría, por ejemplo, hacer una aplicación VFP que utilice MSMQ (Microsoft Messaging Queue
Server), y detecte los eventos asociados a las colas de mensajes. O bien una aplicación de automatización de
envío y recepción de emails, que responda a eventos de Outlook.

Esta funcionalidad se implemente a través de 3 métodos de la clase comutil, que son:

 ExportEvents
 BindEvents
 UnBindEvents

El método ExportEvents es para ser usado en “tiempo de desarrollo”. Permite exportar la interfaz del objeto
COM (es decir, qué eventos genera) a una clase VFP. La clase VFP se genera en un archivo de texto (es decir,
la definición está hecha en forma programática - no visual -, con DEFINE CLASS .... ENDDEFINE).

A partir de esa “cáscara”, se puede desarrollar una clase, que tenga los métodos correspondientes para “atender”
a los eventos de la clase COM.

En tiempo de ejecución, a través del método BindEvents se realiza la asociación entre el objeto COM y un
objeto de dicha clase VFP. Las siguientes líneas de código muestran cómo asociar una clase VFP a un objeto
COM, en este caso, de la clase ADODB.Connection:

oUtil = createobject('vfpcom.comutil')

oConn = createobject('ADODB.Connection')

* ADOConnEvents es una clase VFP,

* desarrollada con la ayuda del método ExportEvents

oMonitorADOConn = newobject('ADOConnEvents','MisClases.prg')

oUtil.BindEvents(oConn, oMonitorADOConn)

A partir de ese momento, cuando el objeto Connection (oConn) genere un evento, se invocará el método
correspondiente de la clase ADOConnEvents.

¿Para qué usar algo nuevo?

Ahora bien: supongamos que nos tomamos el tiempo de estudiar y entender el modelo de objetos de ADO y el
uso de sus propiedades y métodos, y aprendemos a usarlo desde Visual FoxPro. La pregunta que queda por
hacernos es: ¿cuáles son las razones para utilizar un mecanismo nuevo ?. Visual FoxPro, a través de los
mecanismo de Vistas Remotas y de SQLPassThrough ofrece mecanismos más que suficientes para desarrollar
una aplicación robusta y de buen desempeño.

Una primera razón sería la de poder utilizar las características y posibilidades de OLE DB para acceder a una
fuente de datos para la cual dispongamos del correspondiente OLE DB Provider, por ejemplo, a Microsoft SQL
Server. Características dentro de las cuales se pueden incluir cuestiones de performance o el uso de nuevas
funcionalidades, como ser la obtención de Recordsets jerárquicos (o Data Shapes) a través del uso del provider
MSDataShape y la instrucción SHAPE, disponibles si utilizamos ADO.

Una segunda razón podría ser, simplemente, el querer utilizar una tecnología más moderna y con más potencial
en cuanto a su evolución futura, de manera de prepararse mejor para la próxima generación de herramientas de
desarrollo.
Una tercera razón, quizás la de mayor importancia, es si nos encontramos ante la necesidad de desarrollar una
función o método de un componente o clase, al cual se debe enviar, o del cual se deba recibir, un conjunto de
datos, es decir, una serie de registros del mismo tipo, cuya cantidad pueda ser variable (por ejemplo, las líneas
de detalle de un Pedido). Si se trata de una función o método que va a ser utilizada por otro componente
también desarrollado en Visual FoxPro, la solución a esta necesidad, podría resolverse mediante el uso de
cursores nativos de Fox. Pero si es necesario que dicho componente sea implementado como una clase COM,
entonces es que se hace necesario buscar otra alternativa. Existe la posibilidad de utilizar vectores o conjuntos
de caracteres concatenados, o hasta la posibilidad de utilizar XML. En todos estos casos, se deberán desarrollar
mecanismos de preparación (codificación o armado) y recepción (de-codificación o parseo) de los datos, que
inevitablemente resultarán en código extenso y, probablemente, difícil de mantener. La alternativa de utilizar
ADO, ofrece un mecanismo simple y elegante para satisfacer este necesidad. Es decir, el intercambio de
información entre el componente desarrollado en Visual FoxPro y sus clientes, se implementará a través del
envío y recepción de RecorSets ADO.

Conclusiones

Si bien la decisión de qué mecanismos utilizar en cada caso particular, dependerá del tipo de aplicación y de las
necesidades de funcionamiento y performance que se definan, así como de la posible evolución de una
determinada aplicación, nos parece que, dada las características del uso de ADO en la presente versión de
Visual FoxPro, es recomendable utilizarlo solamente en aquellos casos en que encontremos un beneficio real.
Como se dijo, los mecanismo nativos disponibles, ofrecen un grado de productividad mayor, a la vez que un
resultado en términos de calidad de la aplicación más que suficientes.

También es cierto, como se dijo, que probablemente las próximas versiones de Visual FoxPro, ofrezcan una
mayor integración y permitan aprovechar esta tecnología, de una manera más productiva y eficiente.

Referencias

 Si bien al instalar los componentes de ADO 2.5 (mdac_typ.exe, que puede obtenerse en:
http://www.microsoft.com/data/download.htm), se instala la documentación básica de ADO, en la
instalación del SDK (http://www.microsoft.com/msdownload/platformsdk/setuplauncher.htm), se puede
instalar una conjunto de documentación, tutoriales y ejemplos mucho más extenso.

 En el sitio de MSDN, puede obtenerse un artículo de John Petersen, específico acerca del uso de ADO
con Visual FoxPro: ADO Jumpstart for Microsoft Visual FoxPro Developers
(http://msdn.microsoft.com/library/techart/ADOJump.htm)

 Libros
o Programming Ado - David Sceppa - Microsoft Press - ISBN: 0735607648
o PROFESIONAL ADO 2.5 Programming – David Sussman, James Conard, Brian Matsik – Wrox
Press – ISBN 1-861002-75