Pre Conferencias

Por Amby

 Es la mañana del 13 de octubre del 2005, amanece soleado y me dispongo a comenzar la primera jornada, en este caso, la jornada previa a la Conferencia Southwest Fox 2005. El hotel donde estoy hospedada no tenía servicio de desayuno; pero el café de al lado suplía esa ausencia. Desayuné, todo listo y ¡ a empezar la fiesta ! El evento se desarrolló en la Universidad Estatal de Arizona (ASU) en el Memorial Union. La Universidad es el corazón de la ciudad, hay edificios por doquier y muchos de los trabajadores de los servicios estudian en esta universidad.

En el segundo piso del Memorial Union estaban los organizadores, pasé a inscribirme. En la inscripción nos dieron dos libros de excelente calidad. Son: "What's New in Nine: Visual FoxPro's Latest Hits"  y ".NET for Visual FoxPro Developers". Yo los había leído los dos; pero no está mal.... teniendo a los autores presentes me llevaré una copia firmada ¡¡ yupi yupi !!

La mañana empezó con Utilizando Servidores COM de Windows (Using Windows Component Services (COM+)) por Craig Berntson

La sesión estuvo dividida en dos partes. Craig nos introdujo el tema y nos fue llevando con ejemplos hasta mostrarnos que aquello que parecía tan difícil podía a llegar a ser sencillo.

Los Component Object Model (COM) han sido utilizados desde hace muchos años, cada vez que automatizamos Word, Excel u Outlook, desde aplicaciones VFP, estamos trabajando con COM. Para crear un componente COM basta con definir una clase sin olvidar la cláusula OLEPUBLIC, que es la que indica al compilador que se va a crear un componente COM.

Un ejemplo de código para una clase Calculo que realice, entre otras funciones, el cálculo de media aritmética, puede ser:

DEFINE CLASS Calculo AS SESSION OLEPUBLIC
  FUNCTION Media(tnInferior AS Integer, tnSuperior AS Integer) AS Integer
    *** calcula la media artimética y devuelve su resultado
  ENDFUNC
ENDDEFINE

Luego, guardarla como un .PRG, por ejemplo BOCalculo y generarla como Servidor COM de subproceso único (Single-threaded COM server (DLL)). Cuando se genera un componente COM, se generan varias entradas del registros que apuntan a la carpeta y al archivo que se compiló. Se crea un archivo con el mismo nombre de la aplicación y extensión TBL que contiene datos muy interesantes que nos pueden ayudar a encontrar errores en la generación del COM (a mi una vez me pasó que estaba referenciando a otro proyecto y casi cuando ya me volvía loca, este archivo me dio la respuesta). Se llama type library y debe ser distribuido junto con las DLLs de VFP cuando distribuimos aplicaciones.

Para emplear el COM creado, utilice el ejemplo:

loCom = CREATEOBJECT(“BO.Calculo.Calculo”) && Instancia el COM 

A partir de aquí podemos emplear IntelliSense, llamar a sus propiedades y métodos, asignar nuevos valores, tal y como hacemos con cualquier otro objeto en VFP.

Vistos así, queda muy claro que es bastante sencillo, crear, compilar y utilizar COM desde VFP. Seguimos adelante...¿qué es DCOM?

En el caso de Distributed Component Object Model (DCOM), el componente se instala se instala en un PC remoto, generalmente en un servidor. El proceder es bastante similar, sólo que en este caso la comunicación entre la petición y el resultado pasa a través del servidor. Una ventaja del empleo de DCOM sobre COM es que el componente está centralmente localizado en el servidor, por lo que no será necesario distribuirlo, los cambios en el componente será necesario actualizarlos únicamente en el servidor.

Ajá, bien, seguimos avanzando ... y los COM+?

Los Windows Component Services, también denominados COM+, trabajan de igual forma que los DCOM, aunque los COM+ pueden trabajar en modo desconectados.

Los COM+ brindan servicios adicionales a los DCOM, entre las que podemos enumerar: Administración, Seguridad, Control de transacciones, Activación justo a tiempo (JITA), componentes de cola, Balanceo dinámico de carga, etc.

Vimos un ejemplo de la creación de un componente dinámico. La única diferencia van a ser 3 líneas de código. Se crean otros objetos dentro de nuestro componente (empleamos CreateObject) y lo vamos a crear y destruir dentro de cada método que lo va a necesitar.

En este caso se selecciona Servidor COM de subproceso múltiple Multi-threaded COM server (DLL) . Sobre las diferencias de estos enfoques se puede decir que hay varios modelos, por ejemplo en el Apartment-Model Threaded varios componentes conviven como si fueran apartamentos de un mismo edificio; pero a su vez están separados, no conviven juntos.

Antes de utilizarlos hay que instalar el componente COM+. Para ello empleamos el Servicio de Componentes. No me voy a detener porque fue muy detallado en el artículo Web Services y VFP8 publicado por Ignacio Amorós Cantó (Alicante, España) y que podemos ver en  http://www.portalfox.com/article.php?sid=1074

En este caso crea una nueva aplicación con seguridad a nivel de usuario. Cuando se ejecuta desde VFP se ve que el componente comienza a rotar y esto ocurre justo al ejecutar el comando Createobjetct que crea una instancia del componente, se detiene asignando NULL

Como hemos dicho, los objetos COM+ emplean instalación justo a tiempo (JITA) y trabajan sin estado. Esto significa que en realidad la función CREATEOBJECT()  no instancia el componente en realidad. En su lugar, conecta el runtime del COM+, quien a su vez, instancia el componente, a través del uso de un proxy. Si ocurre un llamado a SetComplete() o SetAbort() el COM+ libera el componente; pero el proxy se mantiene. Por eso los siguientes llamados ocurrirán mucho más rápido porque la Activación justo a tiempo mantendrá una copia del componente en memoria por un período de tiempo después de haberlo "cerrado".  Sobre el trabajo sin estado podemos decir que los componentes COM+ son capaces de adaptarse a miles de usuarios, con sus costes de rendimiento implicados, en dependencia del código en los métodos Init y Destroy.

Para emplear estos COM+ es necesario tener otra aplicación del lado del Cliente. Esta aplicación también se instala utilizando Servicios de Componentes. Vimos este caso con un ejemplo.

La Seguridad es una parte muy importante en las aplicaciones. El runtime COM+ controla la seguridad por nosotros, desde allí es que se configura y no desde el programa de VFP. Está basada en roles, se asignan roles específicos a los usuarios, la aplicación COM+, los componentes e incluso a métodos dentro de ellos. Empleamos los grupos de Seguridad de Windows. En el ejemplo que vimos no había ningún control por parte de VFP, ni una línea de código, aunque Craig aclaró que se puede establecer unos mensajes para el control de errores.

Sobre las transacciones, Craig ha dicho: ..." las transacciones son las sombrillas bajo las cuales deben realizarse las actualizaciones seguras de los datos...." Deben garantizar una copia del original antes de actualizar, permitir deshacer todo y controlar el riesgo que significa modificar los datos.

Una transacción completa debe seguir cuatro reglas, llamadas ACIDity:

Atomicidad: Se realiza todo o nada
Consistencia: La transacción es una transformación correcta del estado del sistema.
Aislamiento (Isolation): Garantizar que de ser necesario se realiza el RollBack
Durabilidad: La actualización puede sobrevivir a los errores. Por ejemplo, si el servidor pierde la energía antes de que todas las tablas hayan sido actualizadas, aquellos cambios realizados son inmediatamente deshechas. Por ejemplo, las tracciones en VFP no cumplen con ACIDity porque no son duraderas.

Pues... nos hemos ganado un receso, no creen? ¡ Qué bien hemos empezado! Está muy interesante y aun nos queda hora y media del tema, dice Craig que seguiremos con las transacciones ... Salí a tomar aire ... en el pasillo estaba Rick Shummer acabadito de llegar, estuvimos conversando y de paso me firmó el libro, su dedicatoria fue: " Espero que disfrutes trabajando con VFP 9 y desarrollando aplicaciones" - Gracias Rick !!

Toca regresar a toda prisa ... creo que ya han comenzado ... uy si, espero no haberme perdido mucho.

Para las tracciones desde COM+ las bases de datos necesitan tener un Administrador de Recursos. VFP no tiene; pero puede participar en transacciones COM+ utilizando Compensating Resource Manager.

Existen ventajas en utilizar transacciones COM+:

• Actualizar múltiples bases
• Soporte para bases de datos como SQL Server y Oracle
• Apto para el trabajo con Internet a través de TIP (Transaction Internet Protocol)
• BYOT (Bring Your Own Transaction). Esto se realiza a través de Compensating Resource Managers y TIP.
   

Para trabajar las transacciones, El runtime COM+ emplea Microsoft Distributed Transaction Coordinator (MSDTC). Esto significa que las transacciones se controlan fuera de la Base de datos. Trabaja muy bien porque la transacción se realiza empleando un doble pase. En el primer pase, el MSDTC consulta cada base de datos, buscando si puede guardar los datos. Una vez que cada base de datos ha contestado, comienza el segundo pase, en el que, si todas han respondido que pueden se actualizan y si al menos alguna no puede, pues se realiza rollback de cada una de ellas.

Retomemos el Compensating Resource Managers (CRM). Habíamos visto hasta ahora el Resource Manager (RM), el que está fuertemente integrado en el Distributed Transaction Coordinator (DCT). El CRM proporciona una vía rápida y fácil de integrar los recursos de aplicaciones en el DCT. Consiste en un par de servidores COM. El primero, CRM Worker, escribe el log de las acciones que deben realizarse en caso de tener que recuperarse o ejecutar la acción principal, como puede ser añadir un registro. El segundo es el CRM Compensator, que se instala por el sistema CRM al final de la transacción, ya sea exitosa o revocada. La siguiente figura muestra este proceso.

• La aplicación instancia el objeto de negocio. El objeto de negocio se ejecuta dentro del COM+.
• El objeto de negocio instancia el CRM Worker.
• El CRM Worker instancia el Log Control, que como hemos dicho es parte del COM+. El nombre del Servidor COM para el Compensador se pasa como parámetro al Log Controller.
• El objeto de negocio llama a los métodos del objeto COM+ Context para realizar o abortar la transacción.
• El COM+ llama al Log Controller para realizar o abortar la transacción.
• Debido a que el CRM Compensator tiene un gancho a los eventos del Log Controller, es automáticamente llamado y controla la realización o no de la transacción.

Para configurar el CRM en un COM+ volvemos al Asistente y en la ficha Avanzados marcamos la casilla Habilitar los administradores de compensación de recursos (Enable compensating resource managers). De todo esto Craig ha mostrado ejemplos.

Sobre Componentes asincrónicos y Componentes en cola (Queued Components) . Existen algunas ventajas de emplear componentes en cola, ya que minimiza los efectos de la desconexión de una estación de trabajo o el servidor. Son frecuentemente llamados Messaging Components, porque funcionan mediante la transmisión de mensajes. La diferencia se puede ver comparando estas figuras:

En este caso, una aplicación síncrona,  la estación de trabajo llama al primer componente Orders que escribe en la DBC Orders y a su vez llama al componente Shipping. Todo el proceso ocurre en una única transacción.

Observe que están involucradas varias transacciones. La estación de trabajo  envía mensajes a la cola intentando acceder al componente  Orders. Cuando Orders está disponible recoge el mensaje, comienza la transacción y escribe los datos en la DBC Orders. Escribe un mensaje en otra cola que es leído por el componente Shipping para actualizar la DBC Shipping. Cada cola es a su vez transaccional incluso cuando los componentes no están disponibles.

Las barras amarillas son los denominados Recorders. La infraestructura del COM+ dispone de recorder, listener y player. Lo que ocurre es que cuando se activa un componente un listener oye que se ha grabado un mensaje por el recorder al Componente y lo pasa al player. El player es quien ejecuta el mensaje en el componente.

Los Queued Components utilizan Microsoft Message Queue (MSMQ), por lo que hay que asegurarse de tenerlos bien instalados.

Como conclusiones Craig nos dice que Windows brinda muchos servicios que permiten robustecer nuestras aplicaciones y son muy fáciles de diseñar, desarrollar, controlar y configurar. Los COM+ estarán en uso durante mucho tiempo aun en las futuras tecnologías, por lo que conviene entenderlos y aplicarlos correctamente.

Hemos terminado. ¿Qué les ha parecido? A mi me ha parecido muy profundo, la mayoría de las cosas me son desconocidas, habrá que retomarlas, estudiar y probar todo para hacerse con estos temas. Quisiera poder traducir este tema, a ver si podemos ... aun no lo se.

Hay un debate y no me muevo de mi asiento. Para esta segunda Conferencia Fox en EE.UU., me propuse prestar más atención a los nombres de las personas que aparecen en las credenciales, porque la vez anterior pude reconocer prácticamente solo a los gurús. Pues mi primera sorpresa fue al final de esta sesión. Uno de los presentes estaba muy activo debatiendo con Craig Berntson y cuando miro el nombre era Craig Boyd, ¡ qué emoción ! Craig Boyd es hoy por hoy una de las figuras más activas en la comunidad, he tenido el placer de intercambiar correos con el y poder traducirle algunos trabajos. En cuanto tenga un tiempito le dedicaré un artículo en la sesión "Conoce a los gurús de Visual FoxPro"

Pues terminó el debate y nos conocimos. Me dijo estar muy satisfecho con las traducciones e inmediatamente me preguntó de qué nos preocupaba a los hispanohablantes en materia de VFP. Ups ! Me tomó un poco por sorpresa; pero bueno,....  le comenté de los debates en los foros y de las dudas que esperamos esclarecer en esta Conferencia. Le dije que esperábamos que las noticias sobre el futuro del Fox fueran buenas. Me aseguró que si .... ¡ Bien !

Almorcé en la propia Universidad, algo rápido... adivinan? Exacto... una hamburguesa ... la primera de muchas ... Pasé por el hotel que está como a 10 minutos de la Universidad, dejé mis cosas, me refresqué un poco y lista !!! De nuevo a clases, esta vez a ver a un conocido de PortalFox, Andy Kramek.

Así pues, tomo asiento en espera del tema Diseñar e implementar Capas de acceso a datos en Visual FoxPro, le pedí a Andy Kramek, que nos hiciera una foto a los asistentes.

En ocasiones programamos aplicaciones de escritorio con tablas nativas de VFP, sin considerar que vamos a necesitar en el futuro otro contenedor para nuestros datos. Pero siempre hay que tener en cuenta la posibilidad de la necesidad de migrar.

Entre las ventajas de VFP como contenedor de Base de datos tenemos: Es perfectamente capaz de realizar todas las operaciones estándar (añadir, actualizar y eliminar registros), tiene un buen motor SQL y brinda un excelente soporte para las vistas, procedimientos almacenados, valores predeterminados, etc. Debemos admitir que los desencadenantes son bastante frustrantes; pero tienen un rango de posibles alternativas que lo hacen una utilidad significativa. VFP no requiere licencia a nivel de usuario final. Entre las desventajas se pudiera decir que tiene un tamaño limitado, ningún archivo puede exceder 2 GB, lo que ya es bastante grande. Pero, si comparamos los 2 GB o 4 GB por base de datos que brinda MSDE y SQL Server respectivamente vemos que los límites de VFP son muy generosos.

¿Por qué entonces movernos hacia datos remotos? Pues básicamente por tres razones fundamentales que veremos detenidamente.

• Seguridad de los datos
• Integridad de los datos
• Accesibilidad de los datos

Sobre la seguridad de los datos, vemos que hay dos niveles que tenemos que considerar a la hora de comparar la seguridad de VFP con un servidor remoto. Lo primero es el aspecto físico. Las tablas de datos se guardan en discos, como archivos separados, los que son muy vulnerables a daño accidental o intencionado. Además donde quiera hay un visor de DBF, en Google con una búsqueda no muy estricta hay más de 300 utilidades, gratis, descargables, con complejidad variable, que deja muy vulnerables a las DBF. Aunque se pueden encriptar los datos siguen siendo inseguras. Por su parte, las tablas remotas garantizan la seguridad física, sólo es posible eliminar los datos eliminando por entero la Base de datos; pero ya esto es más complejo, se requiere de login para acceder primero al servidor y otro para la Base de datos. Incluso se puede controlar el acceso a una tabla o campo determinado.

La integridad de los datos está relacionada con el uso que se hace de los datos. Las aplicaciones que trabajan contra servidores no trabajan directamente con los datos, sino con copias locales, o extractos. Las transacciones, reglas y desencadenantes, se emplean por las bases de datos para asegurarse de que sea mantenida la integridad. La regla básica es que la Base de datos sea ACID.

La accesibilidad es un punto clave, por una parte el acceso a las tablas de VFP se produce de forma directa, esto es tan válido tanto para el desarrollador como para el usuario y esto puede ser bueno y malo según se mire.

Pero no todo son ventajas, entre las desventajas de una Base de datos remota podemos citar:

• No hay acceso directo a los datos
• No existen índices lógicos
• Hay costes adicionales de implementación de un Servidor dedicado
• Existen costos de equipamiento (hardware)
• Costos de software
• Mantenimiento

Vimos aspectos relacionados con el tipo de conexión que podemos utilizar: OLE DB u ODBC, para este caso, no tiene importancia cuál de ellas escoger. Luego pasamos al proceder para conectarnos: puede ser con una cadena de conexión explícita (a veces se llama conexión DNSLess) y la función SQLSTRINGCONNECT o un DataSource Name (DSN) y la función SQLCONNECT(). Al final el resultado es el mismo.

Los controladores de conexión (connection handles) son los valores devueltos luego de establecer la conexión.

Andy comentó sobre las funciones que desde VFP soportan SQL Pass Through y sobre las transacciones, aclarando que en este caso, el valor predeterminado es que sean controladas desde el servidor.

En este punto, Andy Kramek comienza a explicar cómo se diseñó la capa Data. Lo primero fue presentar el modelo lógico para la aplicación que se muestra a continuación.

Aquí vemos las capas (tiers) definidas de forma tal que pueden estar físicamente separadas y los estratos (layer) identifican los componentes funcionales dentro de las capas. Los mensajes van sólo de izquierda a derecha y de un estrato a otro estrato. Las respuestas siempre van de derecha a izquierda y no pueden saltarse un estrato.

Vamos a asumir que la capa presentación (Presentation Tier) es una aplicación VFP. Para controlar las conexiones podemos crear un controlador que se encargue de controlar todos los tipos de conexiones y funcione como una caja cerrada a la que accedan todas las conexiones a Bases de datos, o por el contrario crear subclases que se conecten por separado a cada Base de datos. Ahora, para controlar el SQL agregamos otro objeto en nuestro modelo al que nos referimos como "Behavior" y puede crear una subclase específica para controlar en comportamiento de diferentes versiones de una base de datos.

El diseño para la clase Data ha quedado finalmente de esta forma

Los mensajes entre la presentación y la capa media se realiza a través de la referencia que tiene el objeto al Data Manager. El objetivo de la capa Data es la implementación del diseño lógico para brindar una interfaz de programación entre la aplicación de VFP y sus datos. Los componentes resultantes son: DataSet, Cursores, DataManager, Connection Manager y Behavior Manager. El desarrollador va a interactuar sólo con los dos primeros.

Vimos con ejemplos, el funcionamiento de la clase Data tanto para VFP como para SQL Server

• Crear logins y DSNs
• Establecer la conexión al metadato
• Crear definición de cursores
• Crear definición de dataset
• Instanciar el administrador de datos
• Crear el dataset
• Utilizar el dataset en el código

Esta clase está lista para ser utilizada, sólo será necesario indicar la DSN y cambiar las propiedades que le permitan pasar la DBC a un Servidor remoto SQL.

Pasamos al ejemplo concreto, Andy nos muestra el funcionamiento de la clase, en este caso muestra los resultados cambiando las bases de datos. Es interesante como se puede ver la diferencia que existe entre la búsqueda en VFP y en SQL Server. Mientras la búsqueda en VFP es con reconocimiento de mayúsculas y minúsculas, en SQL no lo es. Entonces, si buscamos por ejemplo la cadena BA para inicio de ciudad, VFP devuelve 0 (porque las ciudades solamente tienen la primera letra en mayúscula), mientras SQL devuelve un conjunto de datos. Todos estos elementos han de ser tenidos muy en cuenta cuando se trabaja con múltiples orígenes de datos.

Otro ejemplo, la clase Cursor Manager, que nos posibilita crear conexiones y configurar el contenido del comando SELECT SQL. Funciona para una sola tabla, la propuesta es crear tantas sentencias SQL como tablas haya que procesar.

Este trabajo es excelente y si nos dedicamos a buscar un poco en su interior, tenemos una información muy valiosa tanto para aplicar en los desarrollos como para aprender buenas técnicas de programación. Con la generosidad que le caracteriza, Andy Kramek ha autorizado la traducción de esta sesión y del resto de las sesiones que presentó en esta conferencia. Junto con la traducción, publicaremos estas clases.

A mí me ha gustado mucho esta primera parte, vamos a descansar un poquito. Aprovecho para comprar algo de beber. Este edificio de la Universidad Estatal de Arizona está dotado de varias cafeterías, hamburgueserías, cafés, una heladería y hasta un pequeño supermercado. Los estudiantes tienen para escoger. Me quedan unos minutos y exploro escaleras abajo... más cafeterías, un salón bien grande con unos butacones, también grandes y un televisor ... siii adivinaron... era grande también. Estaba vacío; pero yo podía imaginar a los muchachos disfrutando de un partido de fútbol rugby. En la sala contigua hay un grupo de mesas de billar y un poquito más allá varias PC conectadas a Internet... interesante, es bueno saberlo, anoche no me pude conectar desde el hotel ... Hay que regresar a clases... a ver que otras cosas interesantes nos cuenta Andy.

Si necesitamos convertir una aplicación actual para ejecutarla; pero ahora, desde una Base de datos remota, debemos tener en cuenta un grupo de elementos: cambios en la arquitectura del sistema, acceso y control de los datos y retirar la confianza en la funcionalidad de VFP.

Las aplicaciones más fáciles de migrar son aquellas diseñadas y desarrolladas en tres capas; pero esto no ocurre en la mayoría de los casos, lo más común es que están generadas utilizando directamente el motor de datos nativo, el empleo del entorno de datos, los comandos explícitos para abrir y cerrar tablas (use y use in). Por tanto hay que ver la implicación que tendrá sobre la estructura de la aplicación: Hay que saber: ¿Dónde y cómo se abren y cierran las tablas? ¿Cómo se obtienen los datos para ser mostrados en la interfaz de usuario? ¿Cómo se guardan los cambios de datos? Como se puede suponer, puede variar la magnitud de la tarea, desde rehacer la aplicación en su totalidad hasta aprovechar de un diseño en 3 capas y traspasarlos sin grandes complicaciones. También depende de la frecuencia de funciones como RECNO() y los índices. Y otras menos intuitivas como son ABS, CEILING, LOG,  LOWER, LTRIM, RIGHT, RTRIM, SOUNDEX, SPACE, STR, STUFF, UPPER. Todas estas devuelven resultados diferentes en tablas de VFP y SQL Server. Un grupo de funciones y operadores tienen equivalencia: ejemplo, ASC() y ASCII(), CHR y CHAR(), y muchas más, y todas deben ser tomados en cuenta.

Por eso, es necesario determinar, cuanto antes mejor, el esfuerzo que implicará el traspaso de los datos de un contenedor a otro.

Andy Kramek se refirió a cómo podemos Convertir una Base de datos existente, aclarando que convertir una DBC es muy diferente a convertir una aplicación, lo que es totalmente desaconsejado. Para la conversión de los datos se puede tomar la DBC de VFP y recrear una igual en el servidor, o extraer los datos desde una DBC VFP y migrarlos a una nueva estructura creada en el servidor. En realidad, lo que propone Andy es combinarlos, por una parte, crear una DBC intermedia en VFP con la estructura que se corresponda a la estructura que existirá en el servidor y hacer desde VFP todos los cambios necesarios, luego actualizar esta DBC y sólo entonces pasar desde aquí los datos al servidor.

Para obtener la estructura actual de la DBC en VFP existen funciones como: ADBOBJECTS(), AFIELDS(), ATAGINFO(), DBGETPROP().

Para crear una estructura de campos que se corresponda con la DBC destino hay que tener en cuenta la denominación de los tipos, abreviatura y sobre todo los tipos de datos que admite, por ejemplo para datos lógicos (L)  VFP logical y el equivalente en SQL Server es bit. De igual forma hay que tener en cuenta los tipos de índices existentes: Primary en VFP se corresponde a Clustered Unique de SQL Server. Para terminar hay que restablecer las relaciones, para ello emplearemos ALTER TABLE mitabla DROP... Sobre los procedimientos almacenados y desencadenantes no hay forma de hacerlo genéricamente, habría que ver en cada caso, por problemas de sintaxis y equivalencias entre funciones. Por ejemplo: ISNULL() es una función válida tanto en T-SQL y VFP, pero en T-SQL es equivalente con la función NVL() de VFP). Además, hay diferencias en el funcionamiento y pudiera ocurrir que lo que está programado en un procedimiento almacenado generar un desencadenante y esto pudiera no ser lo deseado.

Para pasar los datos tener en cuenta que VFP 9.0 incorporó tipos de campos nuevos y la función cast que permite convertir de una vez tipos de datos.

Antes de terminar, Andy reconoce que no existe un único remedio para convertir una DBC existente en otra remota, se puede proceder de formas diferentes, dependiendo también de la complejidad de la DBC. La creación de la capa de datos intermedia es sólo la mitad del problema. Los ejemplos que nos presentó ellos los están utilizando con aplicaciones y proyectos reales. En una última fase, nos dice que como siempre, en todas las tareas complejas, dividir el problema en tareas pequeñas y tratar cada una por separado nos permitirá avanzar mucho sin realizar un gran esfuerzo.

Un agradecimiento y una foto con Andy, una pequeña charla y salgo conversando con  Cor Bloemendaal, que ha venido desde Holanda, nos vamos a tomar una cerveza para hacer tiempo en lo que empieza el emocionante encuentro con los ponentes. De camino nos encontramos con nuestro compañero SysOp de PortalFox Esparta Palma de México, quien de momento no se nos une, quedamos en vernos luego. Esparta comentó que presenció: VSS/VFP IDE Integration and What's New in Visual SourceSafe 2005 for the VFP Developer  - Bill Fields.

Pues eso, nos tomamos cerveza y ice tea respectivos... creo que no les he contado que tengo un dolor de cabeza, que me lo traje de Madrid y no me quiere abandonar. Y bueno, se nos unieron otros participantes y como suele suceder se habló de experiencias, proyectos, anhelos y mucha expectativa por la Conferencia y por el futuro de Visual FoxPro.

Nos vemos en la próxima entrega, Reporte de la Conferencia Southwest Fox 2005  - Encuentro con ponentes.

Saludos,

Ana
www.amby.net