Guía de Diccionarios de Datos

Transcripción

1 Soluciones abiertas para un mundo cambiante Guía de Diccionarios de Datos

2 Soluciones abiertas para un mundo cambiante Versiones documento Versión Revisado por Páginas Fecha 1.0 Andrea Guimarães Versión inicial. Traducido de Data Dictionary Guide de la ayuda de VDF /01/

3 Índice Introducción a los Diccionarios de Datos... 4 Usando Diccionarios de Datos mientras se desarrolla una aplicación... 4 Usando Diccionarios de Datos cuando se desarrolla una aplicación... 4 Trabajando con Diccionarios de Datos... 5 Creando clases de Diccionario de Datos... 5 Construyendo estructuras de Objeto de Diccionario de Datos... 6 Restricciones y filtros... 6 Usando los objetos de Diccionario de Datos... 7 Usando objetos de Diccionario de Datos con las Aplicaciones de Windows... 7 Usando Objetos de Diccionario de Datos con Aplicaciones Web... 8 Tablas, columnas y filas Consulte lo siguiente Índices Consulte lo siguiente Relaciones Consulte lo siguiente Identidad de disco y RowId Tipo de datos de RowId Funciones globales de RowId La interfaz de Diccionario de Datos de RowId Notas especiales Consulte lo siguiente Página 3 de 18

4 Introducción a los Diccionarios de Datos En Visual DataFlex, la implantación de las reglas de de negocio de su aplicación se expresan y administran completamente por Diccionarios de Datos. Los Diccionarios de Datos crean una capa entre la lógica de aplicación y los datos. Esto aporta las siguientes ventajas: Permite a su aplicación interactuar más eficazmente con su base de datos. Los Diccionarios de Datos aumentan la información de su base de datos de forma independiente a los datos físicos. Protege sus datos - los Diccionarios de Datos se aseguran de que solamente se añadan datos válidos. Centraliza la lógica de aplicación - toda la información y las reglas en un solo lugar. Si tiene que hacer un cambio, hágalo solamente en un lugar y el resto se modificará solo. Los Diccionarios de Datos se definen como clases. Creará una clase de Diccionario de Datos para cada tabla. Estas clases serán usadas mientras esté desarrollando su aplicación. Usando Diccionarios de Datos mientras se desarrolla una aplicación Mientras esté desarrollando su aplicación, las herramientas de apoyo de Visual DataFlex usarán la información en sus clases de Diccionario de Datos para ayudarle en el proceso de desarrollo. Esta información será usada cuando cree vistas de entrada en Windows, informes y páginas web. Studio y sus asistentes usarán el Diccionario de Datos para determinar: Qué tablas deben ser abiertas y cómo están conectadas. Qué tipos de controles deben ser usados para un campo especial (por ejemplo: el tipo de línea, casilla de verificación ) Qué etiquetas y contexto debe ser usado como ayuda para sus controles. Qué listas de consultas (lookup lists) deben ser usadas, cómo deben ser usadas y cuál será su aspecto. Los Diccionarios de Datos facilitan crear aplicaciones sólidas, con buena apariencia y fácilmente mantenible. Usando Diccionarios de Datos cuando se desarrolla una aplicación Los Diccionarios de Datos se añaden a una aplicación creando Objetos de Diccionario de Datos (DDOs). A la hora de desarrollar una aplicación, los DDOs sirven para dos propósitos principales: Coordinan la actividad de la base de datos en los objetos de entrada de datos- (DEOs). Proveen a un programa los servicios de validación y actualización de la base de datos. Página 4 de 18

5 Estos dos propósitos son distintos. Creando una estructura de DDOs, conectando los objetos de manera apropiada y a la vez conectando DEOs a esta estructura, garantizando la actividad de la base de datos de forma coordinada. Todas estas conexiones se programan a nivel de objeto. Las reglas de la base de datos se mantienen actualizadas porque son creadas en una clase de Diccionario de Datos con propiedades y con varios eventos definidos en el Diccionario de Datos. Esto se programa a nivel de clase. Trabajando con Diccionarios de Datos Trabajar con Diccionario de Datos consiste en: Crear una subclase de Diccionario de Datos para cada tabla codificando las reglas de las bases de datos en estas clases. Esto se consigue creando propiedades, funciones y procedimientos. Crear objetos (objetos de entrada de datos) en las vistas, objetos Web y otros componentes. Una estructura de DDO es un grupo de objetos de DD que se conectan para proporcionar el acceso sincronizado a tablas relacionadas. Crear objetos (objetos de entrada de datos) ó métodos (funciones / procedimientos) dentro de las vistas, objeto Web u otro componente que se comunique con sus DDOs. Esto permitirá que vea, cree, edite o borre sus datos. Creando clases de Diccionario de Datos Creará una clase de Diccionario de Datos para cada tabla de su aplicación. Estas clases, basadas en la clase de DataDictionary, permiten que defina la información y se establezcan las reglas para una tabla. Poniendo estas reglas en un único lugar (una clase) no tendrá que repetirlas en cada componente que acceda a la tabla. Las reglas que puede especificar en esta clase son: La estructura de la tabla. Cómo se puede conectar a otras tablas. Definir qué validaciones y propiedades se aplican a cada campo. Qué reglas deben ser aplicadas durante grabaciones (saves), borrados (deletes) y actualizaciones (updates). Otra información como los nombres de etiqueta o texto de ayuda. Todos los cambios de datos pasan por los DDOs. Antes de que se cambien los datos los Diccionarios de Datos los validan para usar las reglas, simples o complejas, que usted ha desarrollado en sus clases de Diccionario de Datos. Los Diccionarios de Datos son una clase tan importante que se ha desarrollado una herramienta visual, Database Builder, para crear y mantener esas clases. Pretendemos que utilice siempre esta herramienta para mantener sus Diccionarios de Datos. Database Builder crea el código fuente para estas clases. En algunos casos este código se genera automáticamente seleccionando las opciones apropiadas en el Database Builder mientras que en otros casos usted creará este código usando el editor de código del Database Builder. Página 5 de 18

6 Para más información acerca del funcionamiento de esta herramienta vea: Definiendo clases de Diccionario de Datos. Construyendo estructuras de Objeto de Diccionario de Datos Un conjunto de tablas relacionadas son representadas en su aplicación como una estructura de objeto (DDO) de Diccionario de Datos. Las estructuras de DDO son creadas dentro de varios objetos contenedores diseñados para manejar DDOs. Algunos de los objetos contenedores diseñados para esto son: DbView: usados por aplicaciones de windows para la introducción de datos. ReportView: usados para pedir informes. BusinessProcess: éstos son utilizados por aplicaciones Windows y Web para manejar y procesar por lotes. cwebbusinessprocess: usados en aplicaciones de Web que proveen todo el soporte posterior (Back end) para sus páginas HTML. cwebservice: usados en aplicaciones de Web para suministrar el soporte para los servicios Web (Web services). Las reglas para montar estructuras de DDO son las mismas para todos estos contenedores. Cada objeto de Diccionario de Datos debe ser creado y conectado a la estructura de forma apropiada. Esto es hecho a través DDOs hijo creando enlaces con los DDOs padre. Cuando se monta apropiadamente, las estructuras de DDO proveen acceso sincronizado a una jerarquía de datos. Según sea necesario se propagan mensajes entre varios objetos DD entregando de esta forma un comportamiento homogéneo y consistente para las operaciones de Buscar, Limpiar, Grabar y Borrar. Además se validan estas estructuras antes de permitir el cambiar datos. El Studio maneja por usted la creación de estructuras de DDOs. Para más información sobre estructuras de DDOs vea: Creando estructuras de Objeto de Diccionario de Datos (DDO). Restricciones y filtros Una tarea adicional de los DDOs es permitir que se puedan restringir y filtrar los registros dentro de un componente. Se soportan dos tipos de restricciones: Cuando un DDO se relaciona con otro, usted podría querer que el DDO hijo muestre solamente los registros que se relacionan con el registro en curso en el DDO padre. A esto se llama Relates- To- Constraint o Restricción por Relación. Una vista o informe puede necesitar solamente de un subconjunto de datos de cada vez. Podría, por ejemplo, especificar clientes y filtrar por una determinada región o provincia. A estos se les llama Filter Constraints o Restricción por filtro. Ambas clases de restricciones (se pueden combinar juntas) se definen dentro de sus estructuras de DDO. Para más información sobre restricciones y filtros vea: Restricciones y Filtros. Página 6 de 18

7 Usando los objetos de Diccionario de Datos El objeto que contiene una estructura de DDO también contiene, a su vez, todos los objetos y métodos necesarios para comunicarse con esos DDOs. Este proceso de comunicación está, por lo tanto, totalmente encapsulado. En algunos casos, esta comunicación ocurrirá entre un objeto de entrada de datos (DEO) y un DDO. Por ejemplo, una ventana contendrá DEOs que permiten que vea y edite sus datos. Cada DEO está asignado a un DDO y toda comunicación entre el DDO y el DEO es automática. En otros casos, la comunicación ocurrirá entre un método (procedimiento o función) y un DDO. Por ejemplo, un objeto de proceso de datos (Business Process Object o BPO), un objeto navegador de web o un objeto de servicio de Web contendrán una estructura de DDO y los métodos que usan el DDO. En todos los casos, los DDOs son usados para el mismo propósito. Tienen que permitirle hacer lo siguiente: Buscar o borrar datos. Proporcionarle información sobre el valor de un campo del DDO. Producir cambios en un valor del campo de DDO. Validar y grabar datos. Validar y borrar datos. En una aplicación de Web, la conexión entre su DDO y DEO (su navegador) es indirecta, o procesada por lotes. Todos los cambios en un DDO son enviados al navegador en formato HTML como un solo evento. Todos los cambios en un DEO (el navegador) son enviados al DDO una sola petición de lote. Su Web Browser Object (WBO) coordina esta actividad. El mismo DDO es capaz de soportar diferentes interfaces (por ejemplo: controles de ventanas, páginas HTML, servicios Web) y por lo tanto, la habilidad del DDO de comunicarse con estas interfaces variará. Sin embargo, la lógica básica de DDO y los servicios de validación están soportados en todas las plataformas. Por ejemplo, las validaciones de campo son siempre ejecutadas antes de una grabación. Puede encontrar más información en cómo usar DDOs en: Usando objetos de Diccionario de Datos en sus componentes. Usando objetos de Diccionario de Datos con las Aplicaciones de Windows Las Aplicaciones de Windows contienen un tipo especial de objeto de entrada que está integrada con los DDO. A estos objetos se les llama Data Entry Object (DEOs) u objetos de entrada de datos. Cada DEO está unido a un campo en una tabla. Además, cada DEO especifica un DDO para que actúe como su servidor. Una vista constará de una estructura de DDO y un número de estos DEOs. Los mensajes, lanzados a menudo por la interacción de usuarios, son enviados del DEO a su servidor DDO. Los mensajes dicen al DDO que lleven a cabo una de las tareas de DDO que están en la lista de arriba (Buscar, Grabar, Borrar, etc ). Cuando el DDO haya terminado la operación solicitada, enviará los mensajes de notificación a todos los DEOs conectados. Los DEOs usarán estas notificaciones para actualizar sus datos y su apariencia. La sincronización entre DEOs y DDOs permite que estos Página 7 de 18

8 objetos de entrada sean completamente Data Aware (Consciente de Datos). Añadiendo muy poco código, podrá crear sofisticadas aplicaciones de entrada de datos. Las Aplicaciones Windows también pueden usar DDOs dentro de informes. Un informe definirá un DDO para actuar como su servidor. Todas las búsquedas serán manejadas automáticamente por mensajes enviados del informe al servidor DDO. No es necesario el uso de DDOs en informes. Hay aplicaciones que usan BPO para manejar actualizaciones personalizadas. Un BPO debe contener métodos personalizados que ejecuten los procesos. Cree su código en estos métodos para controlar la actividad entre el DDO y el proceso. Existe una interfaz completa de Diccionario de Datos que le permite escribir un código que ejecute los mismos tipos de tareas que las que hacen automáticamente los DEOS (por ejemplo: limpiar, buscar, modificar datos, grabar, borrar ). Usando Objetos de Diccionario de Datos con Aplicaciones Web Las aplicaciones Web usan objetos Web para manejar todos los procesos. Hay dos tipos de objetos Web: Objetos de navegador web o Web Browser Object (cwebbusinessprocess) Se emplean para interactuar con el navegador de web basado en páginas. Objetos de Servicios Web o Web Service Objects (cwebservice) Se emplea para proveer servicios de web. Estos objetos están diseñados para contener las estructuras de DDO y los métodos que se comunican con esos DDOs. Un desarrollador interactúa con los DDOs de la misma forma con la que operan con un BPO en una aplicación windows. Los WBO esperan que la interfaz visual sea provista creando páginas HTML. Esas páginas son creadas (programadas) usando un servidor de páginas activas (ASP). Las páginas ASP hacen las llamadas en los WBO. Dentro del WBO cree los métodos para hacer lo que sea necesario. A continuación haga sus métodos disponibles a su página ASP publicando su Interfaz. Además, los WBO contienen una serie de interfaces que dan acceso a sus Diccionarios de Datos. Esto permite que lleve a cabo todas las funciones básicas del Diccionario de Datos (por ejemplo: buscar, borrar, grabar, limpiar, ) sin tener que escribir código en los WBO. Los WBO proveen soporte de servicio web. Un servicio web puede o no necesitar acceder al Diccionario de Datos. Si lo hacen, se puede añadir una estructura de DDO al servicio de objeto web o Web Service Object (WSO) y crear métodos que se comuniquen con los DDOs. Página 8 de 18

9 Diccionario de datos básico y conceptos de tabla 1. Tablas, columnas y filas 2. Índices 3. Relaciones 4. Identificador de registro y RowId 5. Transacciones, bloqueos y soporte multi-usuario 6. Buffers de fichero y Buffers de campo-ddo 7. Grupos de comandos File_field y Field 8. Comandos de ficheros 9. API de la base de datos Página 9 de 18

10 Tablas, columnas y filas Generalmente las bases de datos se definen como una colección de tablas. Las tablas constan de un juego de columnas designadas con un tipo de datos específicos y con una longitud determinada. Los datos en las tablas se denominan filas. Los mensajes de interfaz de Diccionarios de Datos usan la siguiente terminología para describir las bases de datos: FILE- un file (archivo) hace referencia a una tabla. FIELD- un Field (campo) hace referencia a un campo. RECORD- un Record hace referencia a una fila de datos de una tabla. Los mensajes del Diccionario de Datos usan ficheros (files), campos (field) y registros (records) en sus nombres de interfaz. Algunos ejemplos de esto son Main_File, Field_Options, File_Field_Current_Value, y OnNewCurrentRecord. Mientras que la documentación usará algunos de estos términos indistintamente, el uso normal de estos será: La tabla se usa cuando se consultan tablas de la base de datos. Solamente deberá ver la palabra file" en los mensajes de interfaz. El campo se usa cuando se consultan las columnas de una tabla y cuando se hace referencia a la entidad en el Diccionario de Datos que define una columna. Un Diccionario de Datos mantiene las estructuras de la información sobre la columna como valores, etiquetas, y opciones ( Field_Current_Value, Field_Label, Field_Options ) de cada tabla. Éstos serán referencias como campos (fields) dentro del Diccionario de Datos. Los registros (records) se usan para hacer referencia a una fila de datos de una tabla. Consulte lo siguiente Diccionario de datos básico y conceptos de tabla Página 10 de 18

11 Índices En el Diccionario de Datos todas las búsquedas de información se producen usando índices. Los índices se utilizan para encontrar rápidamente registros individuales y para buscar en una tabla (hacia delante o hacia atrás) en un orden específico. Para ser usadas adecuadamente por los Diccionarios de Datos, cada anotación en los índices debe ser única. En otras palabras, los segmentos usados para crear un índice no deben admitir duplicados (deben poder identificar un registro). Generalmente la singularidad está asegurada si se añade el campo de clave primaria como el último segmento(s) del índice. Los índices se definen dentro del Database Builder con un número de índice. Ese número se usa en los Diccionarios de Datos y en el código de sus programas para determinar qué índice debería usarse. Consulte lo siguiente Diccionario de datos básico y conceptos de tabla. Página 11 de 18

12 Relaciones Las relaciones sirven para "normalizar" sus datos. Algunos de los objetivos de la normalización son: 1. La eliminación de grupos repetitivos - Haga una tabla de consulta (lookup list) distinta para cada juego de atributos relacionados, y de una clave primaria a cada tabla. Por ejemplo, podría estar grabando contactos en sus clientes. No deberá guardar los contactos en la tabla de clientes; sin embargo pondrá la información de contacto en una tabla distinta y relacione cada registro con la clave primaria de su tabla de clientes. 2. Eliminar los datos redundantes- Si un atributo depende solamente de parte de una clave multisegmento, retírelo a una tabla distinta. Supongamos que cada contacto que tenga con un cliente es categorizado (llamada telefónica, correo, visita personal, etcétera). Deberá guardar el tipo de contacto en una tabla distinta y relacionar los contactos con los tipos de contactos. 3. Eliminar columnas que no sean dependientes de una clave- Si los atributos no contribuyen a una descripción de la clave, retírelos a una tabla distinta. Por ejemplo, suponga que está almacenando el nombre del cliente, dirección de Empresa y número de teléfono de Empresa. Estos atributos describen el lugar del trabajo del cliente, no el cliente, así que deberá crear una tabla de Empresa y quitar la información de Empresa de la tabla del cliente pasándola a esta nueva tabla relacionando la tabla de clientes con esta otra. Éstas son las primeras tres formas de la normalización de datos y son probablemente las tres que más desee aplicar comúnmente en su base de datos. Las relaciones se representan en Visual DataFlex usando el modelo de clave foránea (foreing key) y clave primaria (primary key): 1. Una relación debe ser definida de tabla hijo a tabla padre. Una tabla hijo define a un campo o conjunto de campos que se corresponden con un conjunto de datos en el padre. El tamaño y el tipo de datos de campo en el padre y el hijo deben ser los mismos. Esta relación se define usando el Database Builder. 2. Los valores de los campos relacionados en el padre (Ej. A, B y C) deben ser únicos y soportados por un índice cuyos segmentos son los mismos que los campos relacionados (A, B, C de arriba). El campo relacionado en la tabla padre es casi siempre su clave primaria y se refiere en el Diccionario de Datos como el campo clave (key field). 3. La tabla hijo generalmente tiene uno o más índices que permiten la búsqueda rápida por los campos relacionados. Esto quiere decir que los primeros segmentos en este hijo debe consistir de los campos a los que se relacionan. Los Diccionarios de Datos utilizan las relaciones en cuatro maneras: 1. Relacionar: cuando un Diccionario de Datos encuentra un registro, todos los DDOs padre encontrarán automáticamente todos los registros relacionados. El DDO padre de esos DDOs buscará y encontrará los registros relacionados en la estructura superior (lo que se dice normalmente hacia arriba ). De esta forma el buscar/relacionar encuentra una estructura entera de registros relacionados. Página 12 de 18

13 2. Agregados: antes de una grabación (save) o búsqueda (find) los valores de los campos relacionados al padre se mueven a los campos relacionados de los hijos. Este proceso de agregar (attach), asegura que la tabla hijo y la tabla padre se relacionen de forma apropiada durante las grabaciones. 3. Restricciones (filtros): una restricción (constrain) de una relación definida en la estructura de un Diccionario de Datos restringe la búsqueda de registros hijo a los relacionados al padre. Esta característica es usada exhaustivamente en aplicaciones tipo cabecera-detalle (por ejemplo en un sistema de introducción de pedidos en donde los detalles-líneas de pedido deben estar restringidos a un pedido). 4. Validaciones y grabaciones: una validación ocurre antes de que suceda una validación de grabación en el DDO Principal y en todos los DDOs padre relacionados. Además, la estructura de DDO es inspeccionada antes de la grabación. Si la estructura entera no está en su lugar, la validación fallará. Cuando ocurre una grabación (save), el registro en el DDO Principal y todos los registros de los DDOs padre son grabados como una única transacción. Básicamente, las relaciones en Diccionarios de Datos permiten que trabaje con una jerarquía de registros como una sola entidad. Consulte lo siguiente Diccionario de datos básico y conceptos de tabla. Página 13 de 18

14 Identidad de disco y RowId Cada tabla necesita un identificador único que identifique cada registro. Este identificador se encarga de encontrar los registros y deberá hacerlo de la forma más rápida posible Algunas bases de datos tienen un identificador de registro incorporado en cada tabla. La base de datos de DataFlex y la de Pervasive.SQL atribuyen identificadores numéricos únicos a cada registro. Estos identificadores, referenciados como Recnum, establecen la manera más rápida posible de encontrar un registro. La mayoría de las bases de datos de SQL como SQL Server de Microsoft y DB2 de IBM no incorporan una identificación de registro. En vez de esto, las tablas en estas bases de datos contienen claves primarias y un índice que provee acceso rápido a cualquier registro a través de esta clave primaria. La clave primaria puede ser definida como una sola columna o una combinación de columnas. El tipo de datos de la columna(s) que forma(n) la clave primaria puede(n) ser de cualquier tipo(s). Si su base de datos soporta Recnum, puede usar comandos basados en Recnum y mensajes de Diccionario de Datos para identificar y buscar registros. // Low level commands using recnum Integer itemprec Move Customer.Recnum to itemprec Clear Customer : Move itemprecnum to Customer.Recnum Find EQ Customer by recnum // Data Dictionary methods using recnum Integer itemprec Integer ifile Get Current_Record of hoddo to itemprec Send Clear to hoddo : Get Main_File of hoddo to ifile Send Find_by_Recnum of hoddo ifile itemprec Si su base de datos usa una clave primaria como único identificador, podrá usar otros comandos y mensajes de Diccionario de Datos para identificar y buscar registros. // low level commands using primary key String stempid Move Customer.Customer_Id to stempid Clear Customer : Move stempid to Customer.Customer_Id Find EQ Customer by 1 // find EQ by index 1 Página 14 de 18

15 // Data Dictionary methods using primary key String stempid Get Field_Current_Value of hoddo Field Customer.Customer_Id to stempid Send Clear to hoddo : Move stempid to Customer.Customer_Id Send Find of hoddo EQ 1 // find EQ mode and index 1 El ejemplo anterior supone que la clave primaria de la tabla de clientes es Customer.Customer_Id y su índice es el 1. Cada tabla tendrá una definición diferente para su clave primaria e índice de clave primaria. Dependiendo de su tabla necesitará modificar el código anterior para soportar una clave primaria diferente, diferentes nombres de campos, diferente índice de clave primaria y diferentes tipos de datos de clave primaria Hay una desventaja muy importante con los métodos anteriores. Se requiere una sintaxis diferente para bases de datos diferentes y para algunos casos también se requiere una sintaxis distinta para cada tabla. Esto quiere decir que es muy difícil escribir un código que pueda ser abstracto aplicado a cualquier tabla de cualquier base de datos. Este tipo de abstracción es un objetivo y requisito de la programación de Diccionario de Datos. Esto se resuelve introduciendo RowIds. El identificador de registro de cada tabla se correlaciona con un tipo especial de datos llamado RowId. Se define la correlación del identificador de registro al RowId al definir la tabla en Database Builder. Una vez correlacionado, un conjunto de comandos de RowId, funciones y métodos del Diccionario de Datos se usan para buscar e identificar registros. Esto permite usar la misma sintaxis con cualquier tabla. // Low level commands using RowId RowId ritempid Boolean bfound Move (GetRowId(Customer.File_Number)) to ritempid Clear Customer : Move (FindByRowId(Customer.File_Number,riTempId)) to bfound // Data Dictionary methods using RowId RowId ritempid Get CurrentRowId of hoddo to ritempid Send Clear to hoddo : Send FindByRowId of hoddo ritempid Usando esta sintaxis de RowId, tendrá una sintaxis única que puede usar en cualquier tabla de cualquier base de datos. Una vez definido, simplemente programe usando RowId. Tipo de datos de RowId Página 15 de 18

16 RowId ritempid1 ritempid2 : Property RowId prilastid : Get prilastid to ritempid1 Move rotempid1 to ritempid2 Set prilastid to ritempid2 RowId es un tipo especial de datos que sirve para almacenar valores RowId. Este tipo de datos tiene un comportamiento. Puesto que el tipo de datos subyacentes puede ser de cualquier tipo o de cualquier combinación de tipos, no puede ser asociado a ningún otro tipo de datos o usado directamente para realizar cualquier tipo de evaluación. En vez de eso se entregan un conjunto de funciones globales de RowId y de métodos de Diccionario de Datos que permiten manipular RowId. Funciones globales de RowId Las siguientes funciones dan soporte de bajo nivel a RowId: FindByRowId GetRowId NullRowId IsNullRowId IsSameRowId SerializeRowId DeSerializeRowId Move (FindByRowId(iFile,riRowId)) to bfound Move (GetRowId(iFile)) to rirowid Move (NullRowId()) to rirowid Move (IsNullRowId(riRowId)) to bisnull Move (IsSameRowId(riRowId1,riRowId2)) to bissame Move (SerializeRowId(riRowId)) to sserializedrowid Move (DeSerializeRowId(sSerializedRowId)) to rirowid Estas funciones permiten que lleve a cabo cualquier evaluación de RowId que se necesite en un nivel bajo: Function RunOrderDtlReport RowId rihdrid Returns RowId RowId riend Boolean bfound Move (FindByRowId(OrderHea.File_Number,riHdrId)to bfound If bfound Begin Set pristartrowid To (NullRowId()) Get DoRunReport To istat Get priendrowid To riend End Else Begin Move (NullRowId()) To riend end Function_Return riend End_Function Página 16 de 18

17 La interfaz de Diccionario de Datos de RowId Los Diccionarios de Datos también proveen una interfaz completa para trabajar con RowId: Send FindByRowId Send ReadByRowId Get CurrentRowId Get HasRecord Send FindByRowId of hoddo ifile rirowid Send ReadByRowId of hoddo ifile rirowid Get CurrentRowId of hoddo to rirowid Get HasRecord of hoddo to rirowid Estos métodos, junto con las funciones globales de RowId se pueden usar para manejar cualquier tipo de programación de RowId usando Diccionario de Datos. Function RunOrderDtlReport RowId rihdrid Returns RowId RowId riend Boolean bfound Integer imain Get Main_File of oorderhea_dd to imain Send FindByRowId of oorderhea_dd imain rihdrid Get HasRecord of oorderhea_dd to bfound If bfound Begin Set pristartrowid To (NullRowId()) Get DoRunReport To istat Get CurrentRowId of oorderdtl_dd To riend End Else Begin Move (NullRowId()) To riend end Function_Return riend End_Function Notas especiales No confunda RowId con clave primaria. Si su base de datos soporta campos de recnum, sus tablas probablemente todavía tendrán una clave primaria (Ej. tendrán un campo o conjunto de campos que están indexados de forma única) que será identificado en su clase de Diccionario de Datos activando la propiedad Key_Field_State. Ese es el campo que usará en las relaciones. Mientras esos campos, en teoría, podrían usarse para identificar RowId, no lo harán porque la definición interna de Recnum de la base de datos provee la manera más rápida de encontrar un registro. Le interesa usar siempre el método más rápido para encontrar los registros. Deberá usar siempre aquel método que su base de datos o controlador provea que es más rápido. Página 17 de 18

18 RowId fue añadido en la versión 11.0 de Visual DataFlex. Antes de esta versión, todas las tablas tenían que soportar un Recnum (ej. todas las tablas tenían que soportar un campo numérico y único). La introducción de Rowid levanta esta restricción. La programación al estilo de Recnum todavía se soporta. Si un desarrollador sabe que todas sus tablas contendrán un Recnum, pueden continuar programando usando comandos y métodos de Recnum. Consulte lo siguiente Diccionario de Datos básico y conceptos de tablas. Página 18 de 18