Guía de Diccionario de Datos

Soluciones abiertas para un mundo cambiante
Gua de Diccionarios de Datos
www.Moose-Software.com www.VisualDataflex.es
Soluciones abiertas para un mundo cambiante
Versiones documento
Versin
1.0
Revisado por
Andrea Guimares
Pginas
Versin inicial. Traducido de Data Dictionary Guide de la ayuda de VDF 12.1
Fecha
31/01/2008
www.Moose-Software.com www.VisualDataflex.es
Gua de Diccionario de Datos
ndice
Introduccin a los Diccionarios de Datos ........................................................................ 9 Usando Diccionarios de Datos mientras se desarrolla una aplicacin ...................................... 9 Usando Diccionarios de Datos cuando se desarrolla una aplicacin ......................................... 9 Trabajando con Diccionarios de Datos .............................................................................. 10 Creando clases de Diccionario de Datos ......................................................................... 10 Construyendo estructuras de Objeto de Diccionario de Datos............................................ 11 Restricciones y filtros .................................................................................................. 11 Usando los objetos de Diccionario de Datos ................................................................... 12 Usando objetos de Diccionario de Datos con las Aplicaciones de Windows .......................... 12 Usando Objetos de Diccionario de Datos con Aplicaciones Web ......................................... 13 Tablas, columnas y filas................................................................................................ 15 Consulte lo siguiente...................................................................................................... 15 ndices ......................................................................................................................... 16 Consulte lo siguiente...................................................................................................... 16 Relaciones .................................................................................................................... 17 Consulte lo siguiente...................................................................................................... 18 Identidad de disco y RowId .......................................................................................... 19 Tipo de datos de RowId .................................................................................................. 20 Funciones globales de RowId .......................................................................................... 21 La interfaz de Diccionario de Datos de RowId .................................................................... 22 Notas especiales ............................................................................................................ 22 Consulte lo siguiente...................................................................................................... 23 Transacciones, Bloqueos y soporte multi-usuario ......................................................... 24 Consulte lo siguiente...................................................................................................... 24 Buffers de fichero y Buffers de campos de DDO ............................................................ 25 Consulte lo siguiente...................................................................................................... 25
www.VisualDataflex.es
Pgina 3 de 92

Comandos tipo File-Field y Field ................................................................................... 26 Consulte lo siguiente...................................................................................................... 26 Los comandos de tablas (File) ...................................................................................... 27 Consulte lo siguiente...................................................................................................... 27 El API de base de datos ............................................................................................... 28 Consulte lo Siguiente ..................................................................................................... 28 El constructor de Diccionario de Datos (Define_Fields) ................................................ 30 Consulte lo siguiente...................................................................................................... 32 Definir los atributos de tabla de diccionario de datos ................................................... 33 Fijar su tabla principal (Main_File) ................................................................................... 33 Consulte lo siguiente ................................................................................................... 33 Campos clave (key Fields) .............................................................................................. 33 Key_Field_State ......................................................................................................... 34 Protect_key_State ...................................................................................................... 34 Consulte lo siguiente ................................................................................................... 34 Proteccin de grabacin y borrado ................................................................................... 35 Read_Only_state ........................................................................................................ 35 No_Delete_State ........................................................................................................ 35 Cascade_Delete_State................................................................................................. 35 Validate_Foreign_File_State ......................................................................................... 36 Consulte lo siguiente ................................................................................................... 36 Definir los atributos de campo de diccionario de datos ................................................. 37 Opciones de campo (Field Options) .................................................................................. 37 Bsqueda automtica (DD_AutoFind) ............................................................................ 38 Bsqueda automtica GE (DD_AutoFind_GE) ................................................................. 39 UPPERCASE (DD_CapsLock) ......................................................................................... 39 Fuerza de escribir (DD_ForcePut) .................................................................................. 40 No-Enter (DD_NoEnter) ............................................................................................... 40
Pgina 4 de 92

No-Put (DD_NoPut) ..................................................................................................... 40 Display_Only (DD_DisplayOnly).................................................................................... 41 Retain(DD_Retain)...................................................................................................... 41 Retain-All (DD_RetainAll) ............................................................................................ 41 Skip-Found (DD_SkipFound) ........................................................................................ 42 Zero-Suppress (DD_Zero_Suppress) ............................................................................. 42 Require (DD_Required) ............................................................................................... 42 Find-Required (DD_FindReq) ........................................................................................ 42 Limpiar opciones de campo .......................................................................................... 43 Consulte lo siguiente ................................................................................................... 43 Validaciones de campo (Field Validations)......................................................................... 43 Casilla de verificacin (Checkbox) ................................................................................. 44 Rangos (Range).......................................................................................................... 44 Verificacin (Check) .................................................................................................... 45 Tablas de validacin (Validation Tables) ........................................................................ 45 Tabla de validacin (Validation Table) ........................................................................... 46 Descripcin de validacin de tabla (Description Validation Table) ...................................... 46 Tabla de validacin de archivo (File Validation Table) ...................................................... 47 Tablas de validaciones de cdigo (Code Validation Table) ................................................ 47 Mtodos de validacin de campo (File Validation Methods) ............................................... 47 Errores de validacin de campo (Field Validation Errors) .................................................. 48 Consulte lo siguiente ................................................................................................... 49 Aspecto del campo......................................................................................................... 49 Mscaras (Masks) ....................................................................................................... 49 Etiquetas (Labels) ....................................................................................................... 49 Ayuda de estado (Status Help) ..................................................................................... 50 Controles de ventanas (Windows Controls) .................................................................... 50 Consulte lo siguiente ................................................................................................... 50
Pgina 5 de 92

Mtodos de entrada y salida ........................................................................................... 51 Mtodo de entrada ...................................................................................................... 51 Mtodo de salida ........................................................................................................ 52 Consulte lo siguiente ................................................................................................... 53 Autoincremento del campo ............................................................................................. 53 Consulte lo siguiente ................................................................................................... 54 Listas de consultas (Lookup lists) .................................................................................... 54 Consulte lo siguiente ............................................................................................... 55 Definir atributos de campos forneos en Diccionario de Datos ..................................... 56 Campos Forneos clave .................................................................................................. 57 Consulte lo siguiente ................................................................................................... 58 Campos Forneos indexados ........................................................................................... 58 Consulte lo siguiente ................................................................................................... 58 Campos Forneos por defecto ......................................................................................... 58 Consulte lo siguiente ................................................................................................... 59 Definiendo Diccionarios de Datos de Padres, Hijos y relaciones externas ..................... 60 Consulte lo siguiente ................................................................................................... 60 Definiendo tablas Padre requeridas ............................................................................... 60 Consulte lo siguiente ................................................................................................... 61 Definiendo tablas Hijo requeridas .................................................................................. 61 Consulte lo siguiente ................................................................................................... 61 Requisitos para grabar (save) ......................................................................................... 62 Consulte lo siguiente ................................................................................................... 63 Requisitos para eliminar ................................................................................................. 63 Consulte lo siguiente ................................................................................................... 64 Cmo trabaja la estructura de validacin DDO................................................................... 65 Modo de validacin ..................................................................................................... 65 Consulte lo siguiente ................................................................................................... 66
Pgina 6 de 92

Sistema y tablas externas............................................................................................... 66 Definir eventos Del Diccionario de Datos ...................................................................... 68 Forward sending mensajes de evento ............................................................................... 69 Eventos de campo definidos por el usuario ........................................................................ 69 Consulte lo siguiente ................................................................................................... 69 Attach_Main_File ........................................................................................................... 70 Consulte lo siguiente ................................................................................................... 70 Backout y Update .......................................................................................................... 70 Consulte lo siguiente ................................................................................................... 72 Clear_Main_File............................................................................................................. 72 Consulte lo siguiente ................................................................................................... 72 Creating (crear) ............................................................................................................ 72 Consulte lo siguiente ................................................................................................... 73 Delete_Main_File ........................................................................................................... 73 Consulte lo siguiente ................................................................................................... 73 Deleting (borrar) ........................................................................................................... 73 Consulte lo siguiente ................................................................................................... 74 Field_Defaults ............................................................................................................... 74 Consulte lo siguiente ................................................................................................... 74 On new current Record ................................................................................................... 74 Notas especiales ......................................................................................................... 75 Consulte lo siguiente ................................................................................................... 75 Relate_Main_File ........................................................................................................... 75 Consulte lo siguiente ................................................................................................... 77 Save_Main_File ............................................................................................................. 77 Consulte lo siguiente ................................................................................................... 78 Update y Backout .......................................................................................................... 78 Consulte lo siguiente ................................................................................................... 79
Pgina 7 de 92

Validate_delete ............................................................................................................. 79 Consulte lo siguiente ................................................................................................... 80 Validate_Save ............................................................................................................... 80 Consulte lo siguiente ................................................................................................... 81 Consulte lo siguiente...................................................................................................... 82 Restriccin relacionada con Relates To Constraints ...................................................... 83 Consulte lo siguiente...................................................................................................... 85 Restricciones de filtro................................................................................................... 86 Tipos de restricciones de filtro ......................................................................................... 86 El archivo de filtro de campo (File.Field Filter) ................................................................ 86 El filtro Constrain-As ................................................................................................... 87 Consulte lo siguiente ................................................................................................... 88 El proceso de creacin de las restricciones (Constraint) ...................................................... 88 Consulte lo siguiente ................................................................................................... 89 Herencia de las restricciones ........................................................................................... 89 Poner restricciones padre en un DDO hijo ................................................................. 91 Consulte lo siguiente ................................................................................................... 91 Optimizacin de bsquedas de restriccin ......................................................................... 91 La propiedad de ordenacin ......................................................................................... 92 Consulte lo siguiente ................................................................................................... 92
Pgina 8 de 92
Introduccin a los Diccionarios de Datos

En Visual DataFlex, la implantacin de las reglas de de negocio de su aplicacin se expresan y administran completamente por Diccionarios de Datos. Los Diccionarios de Datos crean una capa entre la lgica de aplicacin y los datos. Esto aporta las siguientes ventajas: Permite a su aplicacin interactuar ms eficazmente con su base de datos. Los Diccionarios de Datos aumentan la informacin de su base de datos de forma independiente a los datos fsicos. Protege sus datos - los Diccionarios de Datos se aseguran de que solamente se aadan datos vlidos. Centraliza la lgica de aplicacin - toda la informacin y las reglas en un solo lugar. Si tiene que hacer un cambio, hgalo 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 sern usadas mientras est desarrollando su aplicacin.
Usando Diccionarios de Datos mientras se desarrolla una aplicacin

Mientras est desarrollando su aplicacin, las herramientas de apoyo de Visual DataFlex usarn la informacin en sus clases de Diccionario de Datos para ayudarle en el proceso de desarrollo. Esta informacin ser usada cuando cree vistas de entrada en Windows, informes y pginas web. Studio y sus asistentes usarn el Diccionario de Datos para determinar: Qu tablas deben ser abiertas y cmo estn conectadas. Qu tipos de controles deben ser usados para un campo especial (por ejemplo: el tipo de lnea, casilla de verificacin) Qu etiquetas y contexto debe ser usado como ayuda para sus controles. Qu listas de consultas (lookup lists) deben ser usadas, cmo deben ser usadas y cul ser su aspecto.
Los Diccionarios de Datos facilitan crear aplicaciones slidas, con buena apariencia y fcilmente mantenible.
Usando Diccionarios de Datos cuando se desarrolla una aplicacin

Los Diccionarios de Datos se aaden a una aplicacin creando Objetos de Diccionario de Datos (DDOs). A la hora de desarrollar una aplicacin, los DDOs sirven para dos propsitos principales: Coordinan la actividad de la base de datos en los objetos de entrada de datos- (DEOs). Proveen a un programa los servicios de validacin y actualizacin de la base de datos. Pgina 9 de 92

Estos dos propsitos 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) mtodos (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 aplicacin. Estas clases, basadas en la clase de DataDictionary, permiten que defina la informacin 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. Cmo 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 informacin 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 cdigo fuente para estas clases. En algunos casos este cdigo se genera automticamente seleccionando las opciones apropiadas en el Database Builder mientras que en otros casos usted crear este cdigo usando el editor de cdigo del Database Builder.
Pgina 10 de 92

Para ms informacin 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 aplicacin como una estructura de objeto (DDO) de Diccionario de Datos. Las estructuras de DDO son creadas dentro de varios objetos contenedores diseados para manejar DDOs. Algunos de los objetos contenedores diseados para esto son: DbView: usados por aplicaciones de windows para la introduccin 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 pginas 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 travs DDOs hijo creando enlaces con los DDOs padre. Cuando se monta apropiadamente, las estructuras de DDO proveen acceso sincronizado a una jerarqua de datos. Segn sea necesario se propagan mensajes entre varios objetos DD entregando de esta forma un comportamiento homogneo y consistente para las operaciones de Buscar, Limpiar, Grabar y Borrar. Adems se validan estas estructuras antes de permitir el cambiar datos. El Studio maneja por usted la creacin de estructuras de DDOs. Para ms informacin 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 podra 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 Restriccin por Relacin. Una vista o informe puede necesitar solamente de un subconjunto de datos de cada vez. Podra, por ejemplo, especificar clientes y filtrar por una determinada regin o provincia. A estos se les llama Filter Constraints o Restriccin por filtro.
Ambas clases de restricciones (se pueden combinar juntas) se definen dentro de sus estructuras de DDO. Para ms informacin sobre restricciones y filtros vea: Restricciones y Filtros.
Pgina 11 de 92

Usando los objetos de Diccionario de Datos
El objeto que contiene una estructura de DDO tambin contiene, a su vez, todos los objetos y mtodos necesarios para comunicarse con esos DDOs. Este proceso de comunicacin est, por lo tanto, totalmente encapsulado. En algunos casos, esta comunicacin 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 comunicacin entre el DDO y el DEO es automtica. En otros casos, la comunicacin ocurrir entre un mtodo (procedimiento o funcin) 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 contendrn una estructura de DDO y los mtodos que usan el DDO. En todos los casos, los DDOs son usados para el mismo propsito. Tienen que permitirle hacer lo siguiente: Buscar o borrar datos. Proporcionarle informacin 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 aplicacin de Web, la conexin 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 peticin de lote. Su Web Browser Object (WBO) coordina esta actividad. El mismo DDO es capaz de soportar diferentes interfaces (por ejemplo: controles de ventanas, pginas HTML, servicios Web) y por lo tanto, la habilidad del DDO de comunicarse con estas interfaces variar. Sin embargo, la lgica bsica de DDO y los servicios de validacin estn soportados en todas las plataformas. Por ejemplo, las validaciones de campo son siempre ejecutadas antes de una grabacin. Puede encontrar ms informacin en cmo 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. Adems, cada DEO especifica un DDO para que acte como su servidor. Una vista constar de una estructura de DDO y un nmero de estos DEOs. Los mensajes, lanzados a menudo por la interaccin 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 estn en la lista de arriba (Buscar, Grabar, Borrar, etc). Cuando el DDO haya terminado la operacin solicitada, enviar los mensajes de notificacin a todos los DEOs conectados. Los DEOs usarn estas notificaciones para actualizar sus datos y su apariencia. La sincronizacin entre DEOs y DDOs permite que estos
Pgina 12 de 92

objetos de entrada sean completamente Data Aware (Consciente de Datos). Aadiendo muy poco cdigo, podr crear sofisticadas aplicaciones de entrada de datos. Las Aplicaciones Windows tambin pueden usar DDOs dentro de informes. Un informe definir un DDO para actuar como su servidor. Todas las bsquedas sern manejadas automticamente 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 mtodos personalizados que ejecuten los procesos. Cree su cdigo en estos mtodos para controlar la actividad entre el DDO y el proceso. Existe una interfaz completa de Diccionario de Datos que le permite escribir un cdigo que ejecute los mismos tipos de tareas que las que hacen automticamente 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 pginas. Objetos de Servicios Web o Web Service Objects (cWebService) Se emplea para proveer servicios de web.
Estos objetos estn diseados para contener las estructuras de DDO y los mtodos que se comunican con esos DDOs. Un desarrollador interacta con los DDOs de la misma forma con la que operan con un BPO en una aplicacin windows. Los WBO esperan que la interfaz visual sea provista creando pginas HTML. Esas pginas son creadas (programadas) usando un servidor de pginas activas (ASP). Las pginas ASP hacen las llamadas en los WBO. Dentro del WBO cree los mtodos para hacer lo que sea necesario. A continuacin haga sus mtodos disponibles a su pgina ASP publicando su Interfaz. Adems, los WBO contienen una serie de interfaces que dan acceso a sus Diccionarios de Datos. Esto permite que lleve a cabo todas las funciones bsicas del Diccionario de Datos (por ejemplo: buscar, borrar, grabar, limpiar,) sin tener que escribir cdigo 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 aadir una estructura de DDO al servicio de objeto web o Web Service Object (WSO) y crear mtodos que se comuniquen con los DDOs.
Pgina 13 de 92
Diccionario de datos bsico 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
Pgina 14 de 92
Tablas, columnas y filas

Generalmente las bases de datos se definen como una coleccin de tablas. Las tablas constan de un juego de columnas designadas con un tipo de datos especficos y con una longitud determinada. Los datos en las tablas se denominan filas. Los mensajes de interfaz de Diccionarios de Datos usan la siguiente terminologa 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 documentacin usar algunos de estos trminos 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 informacin sobre la columna como valores, etiquetas, y opciones (Field_Current_Value, Field_Label, Field_Options) de cada tabla. stos sern 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
Pgina 15 de 92
ndices
En el Diccionario de Datos todas las bsquedas de informacin se producen usando ndices. Los ndices se utilizan para encontrar rpidamente registros individuales y para buscar en una tabla (hacia delante o hacia atrs) en un orden especfico. Para ser usadas adecuadamente por los Diccionarios de Datos, cada anotacin 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 aade el campo de clave primaria como el ltimo segmento(s) del ndice. Los ndices se definen dentro del Database Builder con un nmero de ndice. Ese nmero se usa en los Diccionarios de Datos y en el cdigo de sus programas para determinar qu ndice debera usarse.
Pgina 16 de 92
Relaciones
Las relaciones sirven para "normalizar" sus datos. Algunos de los objetivos de la normalizacin son: 1. La eliminacin 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, podra estar grabando contactos en sus clientes. No deber guardar los contactos en la tabla de clientes; sin embargo pondr la informacin 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, retrelo a una tabla distinta. Supongamos que cada contacto que tenga con un cliente es categorizado (llamada telefnica, correo, visita personal, etctera). 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 descripcin de la clave, retrelos a una tabla distinta. Por ejemplo, suponga que est almacenando el nombre del cliente, direccin de Empresa y nmero de telfono 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 informacin de Empresa de la tabla del cliente pasndola a esta nueva tabla relacionando la tabla de clientes con esta otra. stas son las primeras tres formas de la normalizacin de datos y son probablemente las tres que ms desee aplicar comnmente en su base de datos. Las relaciones se representan en Visual DataFlex usando el modelo de clave fornea (foreing key) y clave primaria (primary key): 1. Una relacin 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 tamao y el tipo de datos de campo en el padre y el hijo deben ser los mismos. Esta relacin 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 ms ndices que permiten la bsqueda rpida 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 encontrarn automticamente 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.
Pgina 17 de 92

2. Agregados: antes de una grabacin (save) o bsqueda (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 restriccin (constrain) de una relacin definida en la estructura de un Diccionario de Datos restringe la bsqueda de registros hijo a los relacionados al padre. Esta caracterstica es usada exhaustivamente en aplicaciones tipo cabecera-detalle (por ejemplo en un sistema de introduccin de pedidos en donde los detalles-lneas de pedido deben estar restringidos a un pedido). 4. Validaciones y grabaciones: una validacin ocurre antes de que suceda una validacin de grabacin en el DDO Principal y en todos los DDOs padre relacionados. Adems, la estructura de DDO es inspeccionada antes de la grabacin. Si la estructura entera no est en su lugar, la validacin fallar. Cuando ocurre una grabacin (save), el registro en el DDO Principal y todos los registros de los DDOs padre son grabados como una nica transaccin. Bsicamente, las relaciones en Diccionarios de Datos permiten que trabaje con una jerarqua de registros como una sola entidad.
Pgina 18 de 92
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 ms rpida 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 numricos nicos a cada registro. Estos identificadores, referenciados como Recnum, establecen la manera ms rpida posible de encontrar un registro. La mayora de las bases de datos de SQL como SQL Server de Microsoft y DB2 de IBM no incorporan una identificacin de registro. En vez de esto, las tablas en estas bases de datos contienen claves primarias y un ndice que provee acceso rpido a cualquier registro a travs de esta clave primaria. La clave primaria puede ser definida como una sola columna o una combinacin 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

Pgina 19 de 92

// 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 definicin diferente para su clave primaria e ndice de clave primaria. Dependiendo de su tabla necesitar modificar el cdigo 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 mtodos anteriores. Se requiere una sintaxis diferente para bases de datos diferentes y para algunos casos tambin se requiere una sintaxis distinta para cada tabla. Esto quiere decir que es muy difcil escribir un cdigo que pueda ser abstracto aplicado a cualquier tabla de cualquier base de datos. Este tipo de abstraccin es un objetivo y requisito de la programacin 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 correlacin del identificador de registro al RowId al definir la tabla en Database Builder. Una vez correlacionado, un conjunto de comandos de RowId, funciones y mtodos 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
Pgina 20 de 92

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 combinacin de tipos, no puede ser asociado a ningn otro tipo de datos o usado directamente para realizar cualquier tipo de evaluacin. En vez de eso se entregan un conjunto de funciones globales de RowId y de mtodos 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 evaluacin 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
Pgina 21 de 92
La interfaz de Diccionario de Datos de RowId

Los Diccionarios de Datos tambin 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 mtodos, junto con las funciones globales de RowId se pueden usar para manejar cualquier tipo de programacin 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 todava tendrn una clave primaria (Ej. tendrn un campo o conjunto de campos que estn 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 teora, podran usarse para identificar RowId, no lo harn porque la definicin interna de Recnum de la base de datos provee la manera ms rpida de encontrar un registro. Le interesa siempre usar el mtodo ms rpido para encontrar los registros. Deber usar siempre aquel mtodo que su base de datos o controlador provea que es ms rpido.
Pgina 22 de 92

RowId fue aadido en la versin 11.0 de Visual DataFlex. Antes de esta versin, todas las tablas tenan que soportar un Recnum (ej. todas las tablas tenan que soportar un campo numrico y nico). La introduccin de Rowid levanta esta restriccin. La programacin al estilo de Recnum todava se soporta. Si un desarrollador sabe que todas sus tablas contendrn un Recnum, pueden continuar programando usando comandos y mtodos de Recnum.
Diccionario de Datos bsico y conceptos de tablas
Pgina 23 de 92
Transacciones, Bloqueos y soporte multi-usuario

Las transacciones y el soporte de bloqueo de base de datos estn embebidos directamente en el Diccionarios de Datos. Las actualizaciones de base de datos (grabaciones y borrados) son siempre, por lo tanto, seguros a nivel multi-usuario. Administrar las transacciones es un proceso automtico que no requiere ningn esfuerzo adicional de programacin por parte del desarrollador. Retroceso (Rollback) en las transacciones est tambin embebido en el Diccionario de Datos. Si por cualquier razn una transaccin de grabacin o borrado no puede ser terminada, se deshace la transaccin entera y no se realiza ningn cambio en la base de datos. Se bloquea la base de datos durante una transaccin. Las tablas que participan en la transaccin estarn bloqueadas para escritura (write lock). Esto permite que otros usuarios lean datos de las tablas pero no que ellos escriban datos hasta que los bloqueos sean liberados. Los bloqueos se liberan cuando una transaccin ha finalizado como una grabacin exitosa (successfull commit) o con un retroceso fallido (failed rollback). Dependiendo de la Base de Datos los bloqueos se aplican a nivel de registro o a nivel de tabla. Los procesos de DDOs. Transacciones y Bloqueos se comentan con ms detalle en Transacciones y
Diccionario de Datos Bsico y Conceptos de Tabla
Pgina 24 de 92
Buffers de fichero y Buffers de campos de DDO

Cuando se abre una tabla en una base datos, se crea una memoria intermedia (buffer) de fichero conteniendo los valores de los campos para un registro. La bsqueda (find) y limpieza (clear) de registros mueven datos de la tabla (.DAT) a este Buffer. Las grabaciones (save) mueven los datos del Buffer a la tabla. Se definen variables globales, llamadas File.Filed que dan acceso al programa a esos Buffers, permitiendo que los programadores accedan y cambien los datos del registro actual. // Move from file buffer to a variable Move Customer.Name to sName // Move from variable to the file buffer Move sName to Customer.Name Los DDOs (Data Dictionary Objects) mantienen actualizados los Buffers locales, que mantienen la informacin sobre el registro en curso del DDO. A estos se les llama Buffers de campo DDO (DDOField Buffer). Estos Buffers locales permiten a las aplicaciones soportar DDOs mltiples que usan la misma tabla. // Move from DDO-Field buffer to a variable Get Field_Current_Value of hoDDO Field Customer.Name to sName // Move from variable to the DDO-Field buffer Set Field_Changed_Value of hoDDO Field Customer.Name to sName Hay veces que quiere interactuar con los Buffers globales del archivo (.DAT) directamente y otras que quiere interactuar con los Buffers de campo DDO. Esto se comenta con detalle en Entendiendo Buffers de fichero y Buffers de campos de DDO.
Pgina 25 de 92
Comandos tipo File-Field y Field

La informacin del campo de Diccionario de Datos se almacena y se puede acceder a ella a travs de una interfaz de campo. Esta interfaz requiere que pase como parmetros un identificador de campo y a veces un identificador de tabla. Estos parmetros deben ser pasados como valores enteros (Integers). Las palabras clave especiales, Field y File_Field, permiten que pase estos parmetros como nombres en lugar de nmeros. El compilador cambiar estos por las constantes de nmeros apropiadas. Algunos ejemplos de uso de estas palabras clave son:
// use of the field keyword Get Field_Current_Value of oCustomer_DD Field Customer.Name to sName Set Field_Changed_Value of oCustomer_DD Field Customer.Name to sName // use of the File_Field keyword Get File_Field_Current_Value of oOrder_DD File_Field SalesP.Name to sName Set File_Field_Changed_Value of oOrder_DD File_Field SalesP.Name to sName Los comandos de tipo Field son usados con los mensajes de tipo Field. Use estos cuando el objeto de Diccionario de Datos (DDO) que recibe el mensaje posea el campo. En el ejemplo anterior, Customer.Name es definido dentro del DDO de oCustomer_DD. Los comandos de tipo File_Field son usados con los mensajes de tipo File_Field. Use estos cuando el objeto de Diccionario de Datos que recibe el mensaje quizs no posea el campo que puede pertenecer al DDO o a uno de sus DDOs padre. En el ejemplo anterior, SalesP.Name est definido dentro del DDO oOrder_DD pero el campo pertenece al DDO padre, oSales_DD. File_Field se usa en estas situaciones mientras que el DDO desviar el mensaje hacia el DDO apropiado. Para comprender con detalle los comandos tipo File_Field y Field consulten en Entiendo los comandos de tipo File_Field y Field.
Pgina 26 de 92
Los comandos de tablas (File)

El lenguaje de DataFlex soporta varios comandos que permiten que acceda a tablas directamente fuera de los Diccionarios de Datos. Esos comandos son: Buscar Borrar Guardar a Disco Borrar Cerrar Relacinese Attach
Normalmente, cuando use Diccionarios de Datos no necesitar usar estos mandatos. En algunos de los eventos de Diccionario de Datos puede usarlos para manejar las operaciones personalizadas de bajo nivel. Por ejemplo, podra desear llevar a cabo alguno tipo de bsqueda personalizada en el proceso de Relate_Main_File. En estos casos podra usar estos comandos. Adems, podra usar estos comandos y limitar el uso de un Diccionario de Datos. Es ms probable hacer esto cuando se busquen registros. Usar un comando directo para grabar o borrar registros no es recomendable porque estara evitando todas las reglas de validacin que los DDOs hacen cumplir.
Pgina 27 de 92
El API de base de datos

El lenguaje de DataFlex tiene un juego de comandos que permite consultar cualquier informacin sobre sus tablas. Estos son referidos como los atributos del Api de la base de datos. El comando de Get Attribute se emplea para consultar el valor de cualquier atributo de API. Puede usarlos para consultar informacin sobre: Una tabla (nombre, descripcin, nmero de campos, nmero de ndices, nmero de registros). El ndice de una tabla (la cantidad de segmentos del ndice, el valor de cada segmento). El campo de una tabla (tipo de datos, longitud, puntos decimales, nombre del campo).
En vez de crear una capa adicional de la interfaz de DDO para acceder a estos valores, es mejor que acceda a esta informacin directamente dentro de un DDO o de un componente usando el comando de Get_Attribute. La mayora de estos atributos son de bajo nivel por lo que rara vez necesitar acceder a ellos. Si no puede encontrar un mensaje de DDO que devuelva la informacin que necesita, verifique los atributos de API. Dentro de una aplicacin, lo ms solicitado, aparte de los atributos de API, son la longitud de campo y el tipo de datos del campo. El comando Set_Attribute tambin puede usarse para cambiar atributos de la base de datos. Rara vez necesitara hacer esto dentro de una aplicacin.
Consulte lo Siguiente
Pgina 28 de 92
Definir clases de Diccionario de Datos

Antes de que pueda usar Diccionarios de Datos debe crear una clase para cada tabla en su aplicacin. Database Builder se encargar de hacer esto. Aunque Database Builder es una herramienta de diseo visual, el resultado final de esta herramienta es el cdigo fuente. Los Diccionarios de Datos son simplemente un cdigo fuente basado en clases que se complican en su aplicacin. El propsito de esta seccin es describir las caractersticas de una clase de Diccionario de Datos y exponer la interfaz de Diccionario de Datos (ejemplo: exponer el cdigo fuente). Esperamos que use Database Builder para mantener siempre actualizado sus Diccionarios. Parte del cdigo dentro de las clases de Diccionario de Datos es creado y mantenido por el interfaz visual de Database Builder. Otras partes de la clase, en particular los eventos, requerirn que usted cree un cdigo personalizado. Algunas de las propiedades y eventos descritos en esta seccin tambin pueden ser definidas en el nivel de objeto de Diccionario de Datos. Cuando trabaje en el nivel de objeto necesitar saber cmo usar y codificar la interfaz. Una clase de Diccionario de Datos puede ser dividido en dos partes principales: El constructor de Diccionario de Datos: consiste en fijar todos los atributos de Diccionario de Datos. Esto incluye los atributos de tabla, los atributos de campo, los atributos de campo externos (foreing field) y las relaciones de tablas padre/hijo. Todos estos atributos se mantienen fijando propiedades dentro de un procedimiento llamado Define Fields. Eventos de Diccionario de Datos: se llaman varios eventos durante las operaciones del Data Dictionary: la bsqueda, grabar, eliminar y borrar. Estos eventos pueden ser creados para tratar los requisitos personalizados para una tabla. Estos requisitos incluyen fijar los valores por defecto, llevar a cabo las validaciones y controlar las relaciones entre tablas. Adems, el desarrollador puede proporcionar los eventos personalizados y asignarlos a campos. Estos eventos son lanzados por las operaciones especficas como la validacin de campo y navegacin. Todos estos eventos son creados como funciones y procedimientos que el desarrollador debe crear.
Pgina 29 de 92
El constructor de Diccionario de Datos (Define_Fields)

El mtodo de construccin especial, Define_Fields, se emplea para definir todos los atributos del Diccionario de Datos. Este mtodo de construccin define los siguientes tipos de informacin: Atributos de tabla: definen los atributos que son aplicables a la tabla entera. Esto conecta su Diccionario de Datos a una tabla especfica y define las capacidades bsicas del Diccionario de Datos. Atributos de campo: definen atributos para cada columna en su tabla. Esto provee reglas de validacin de campo, reglas de bsqueda y mucha informacin que es usada por los objetos de entrada de datos (DEOS). Atributos de campo externos (foreing): definen los atributos para sus campos cuando el DDO se usa en un padre externo en la estructura DDO. Relaciones de tabla padre/hijo: definen las reglas de relacin entre tablas. Esto sirve para ayudar a construir estructuras DDO y verificar que estas estructuras sean capaces de soportar apropiadamente las actualizaciones de base de datos.
Todos estos ajustes se crean y se mantienen actualizados usando Database Builder. El listado de abajo es un Define_Fields de muestra que fue creado usando Database Builder: Procedure Define_Fields Forward Send Define_Fields //DDB-Generated-Code-Location //DDB-DefineFieldStart Set Main_File To Orderhea.File_Number
Set Foreign_Field_Options DD_KEYFIELD To DD_FINDREQ Set Foreign_Field_Options DD_INDEXFIELD To DD_NOPUT Set Foreign_Field_Options DD_DEFAULT To DD_DISPLAYONLY // Child (Client) file structure................ Send Add_Client_File Orderdtl.File_Number // Parent (Server) file structure............... Send Add_Server_File Customer.File_Number Send Add_Server_File Salesp.File_Number // External (System) file structure............. Send Add_System_File Ordsys.File_Number DD_LOCK_ON_NEW_SAVE_DELETE Define_Auto_Increment Ordsys.Order_Number To Orderhea.Order_Number // Field-based properties....................... // Orderhea.Order_Number Set Field_Options Field Orderhea.Order_Number To DD_AUTOFIND
Pgina 30 de 92

Set Field_Prompt_Object Field Orderhea.Order_Number To (ORDERHEA_SL(Self)) Set Key_Field_State Field Orderhea.Order_Number To TRUE Set Status_Help Field Orderhea.Order_Number To "Order Number - New orders are assigned numbers automatically" // Orderhea.Customer_Number // Orderhea.Order_Date Set Field_Class_Name Field Orderhea.Order_Date To "dbSpinForm" Set Field_Entry_msg Field Orderhea.Order_Date To Entry_Order_Date Set Field_Mask Field Orderhea.Order_Date To "mm-dd-yyyy" Set Field_Mask_Type Field Orderhea.Order_Date To MASK_DATE_WINDOW Set Field_Prompt_Object Field Orderhea.Order_Date To (ORDERHEA_SL(Self)) Set Status_Help Field Orderhea.Order_Date To "Date on which the order was placed" // Orderhea.Terms //DDB/ Comment_Short Field Orderhea.Terms To "Where does this go?" Set Field_Class_Name Field Orderhea.Terms To "dbComboForm" Set Field_Label_Long Field Orderhea.Terms To "Terms" Set Field_Label_Short Field Orderhea.Terms To "Trm" Set Field_Value_Table Field Orderhea.Terms To (Terms_table(Self)) Set Status_Help Field Orderhea.Terms To "Payment terms" // Orderhea.Ship_Via Set Field_Class_Name Set Field_Value_Table Set Status_Help
Field Orderhea.Ship_Via To "dbComboForm" Field Orderhea.Ship_Via To (Ship_Table(Self)) Field Orderhea.Ship_Via To "Shipping method"
// Orderhea.Ordered_By //DDB/ Comment_Short Field Orderhea.Ordered_By To "This is just a suggested list. No parent files support this" Set Status_Help Field Orderhea.Ordered_By To "Order placed by" // Orderhea.Salesperson_Id Set Field_Label_Long Field Orderhea.Salesperson_Id To "Sales Person Id" Set Field_Label_Short Field Orderhea.Salesperson_Id To "Sales ID" Set Status_Help Field Orderhea.Salesperson_Id To "Sales Person who initiated the order" // Orderhea.Order_Total //DDB/ Comment_Short Field Orderhea.Order_Total To "Maintained by the Orderdtl DD" Set Field_Mask_Type Field Orderhea.Order_Total To MASK_CURRENCY_WINDOW Set Field_Options Field Orderhea.Order_Total To DD_DISPLAYONLY // Orderhea.Last_Detail_Num //DDB/ Comment_Short Field Orderhea.Last_Detail_Num To "This is the " //DDB-DefineFieldEnd End_Procedure // Define_Fields El constructor de Define_Fields puede usarse solamente en clases. No puede crear o aumentar Define_Fields dentro de un DDO.
Pgina 31 de 92
Gua de Diccionario de Datos Consulte lo siguiente

Definir clases de Diccionario de Datos.
Pgina 32 de 92
Definir los atributos de tabla de diccionario de datos

Los atributos de tabla de diccionario de datos definen los atributos que son aplicables a la tabla entera. Estos atributos son: Fijar su tabla principal (Set Main_File). Definir sus campos clave (Key Fields). Definir las protecciones de grabacin y borrado.
Fijar su tabla principal (Main_File)

Set Main_File to Customer.File_Number Esto identifica la tabla del Diccionario de Datos. Debe ponerse siempre una vez, y una vez puesto no pueda ser cambiado. Poner esta propiedad es el requisito mnimo de un Diccionario de Datos. La clase de Diccionario de Datos ms bsica podra ser creada de la siguiente manera:
Class cTheMostSimpleCustomer_DD is a DataDictionary Procedure Define_Fields Forward Send Define_Fields set Main_File to MyTable.File_Number End_Procedure End_Class
Definir los atributos de tabla de Diccionario de Datos.
Campos clave (key Fields)

Set Protect_Key_State to true Set Key_Field_State Field Customer.Id to true Los campos clave son campos que han sido designados para identificar los registros en una tabla (ej. Customer_number en una tabla de cliente). La propiedad que se usa para designar el campo clave es Key_Field_State.
Pgina 33 de 92

Una vez designados Foreign_Field_Options. los campos clave puede fijar opciones para todos ellos con
Key_Field_State
Set Key_Field_State Field Customer.Id to true Key_Field_State marca un campo como el campo principal para la tabla. Una ventaja de fijar esta alternativa puede ser prevenir los cambios en los datos guardados en el campo, es decir, no se pueden modificar los datos de un campo clave. Esto se conoce como proteccin de campo clave (Key Field Protection). La proteccin de campo de la clave primaria evita que los datos de los campos que componen la clave primaria se modifiquen una vez que el registro sea creado (por ejemplo: si la clave primaria de una tabla de clientes es cliente.cdigo no interesara modificar el cdigo una vez que ya se haya creado el cliente). Generalmente pondra esta opcin sobre campos de claves primarias como el campo de nmero de pedido en una tabla de cabecera de pedido o el campo de identificacin del cliente en la tabla de clientes. Esto proporciona proteccin de orfandad impidiendo que sean modificados los campos de identificacin usados en las relaciones padre/hijo. Si su clave primaria consta de varios campos, todos los campos de la clave deben ser marcados como campos clave. Los campos clave solamente estn protegidos en una tabla si la propiedad de Protect_Key_State tambin est activada en el Diccionario de Datos.
Protect_key_State
Set Protect_Key_State to true Protect_Key_State determina si los campos que componen una clave primaria deben ser protegidos despus de que hayan sido grabados por primera vez en un nuevo registro. Cuando estn marcados a verdadero (true), un campo identificado como parte de una clave no puede ser editado despus de que haya sido grabado. Esto asegura que los registros hijo que se relacionan con un registro padre a travs de una clave primaria, no se puedan por cualquier casualidad dejar hurfano. Los campos que componen una clave primaria son identificados usando la propiedad de campo Key_Field_State.
Pgina 34 de 92
Gua de Diccionario de Datos Proteccin de grabacin y borrado

Read_Only_state
Set Read_Only_State to True Read_Only_State se usa para especificar que Diccionario de Datos no puede usarse directamente para grabar o borrar registros. Esto quiere decir que los mensajes Request_Save y Request_Delete enviados al DDO generarn un error y no llevarn a cabo ninguna actualizacin. Note que los registros en un Diccionario de Datos de solo lectura (Read_Only) pueden ser modificados o borrados indirectamente por mensajes enviados a otro Diccionario de Datos dentro de estructuras de objeto. Por ejemplo, si el DDO padre es la tabla de cliente y esta se marca como de solo lectura (Read_Only) y el DDO de la tabla de cabecera de pedidos no se marca como de solo lectura (Read_Only), entonces las grabaciones y borrados enviados al DDO de cabeceras de pedidos permitirn modificar estos datos de la tabla de clientes. Esto es necesario para mantener la integridad de la base de datos. Si quiere que una estructura entera de DDO sea solo de lectura, deber fijar toda la estructura de DDOs. Read_Only_State es ms probable que se fije en un objeto de Diccionario de Datos y no en una clase.
No_Delete_State
Set No_Delete_State to True No_Delete_State desactiva borrados directos de los registros. Esto quiere decir que el mensaje que Request_Delete enviado a este DDO generar un error y no llevar a cabo ninguna accin. Este mensaje no afecta a borrados de los registros que son parte de un borrado en cascada.
Cascade_Delete_State
Set_ Cascade_Delete_State to True Cascade_Delete_State especifica cmo afecta una orden de borrados (delete) a los registros relacionados de una tabla hijo, cuando el borrado se enva al padre. Si Cascade_Delete_State es verdadero, entonces los registros de la tabla hijo y todos los registros descendientes sern eliminados. Si la propiedad est a falso, se permitir el borrado cuando no exista ningn registro hijo. Ambos mtodos aseguran que ese registro hijo nunca se deje hurfano.
Pgina 35 de 92

Validate_Foreign_File_State
Set Validate_Foreign_File_State to False Antes de que ocurra una grabacin, querr validar todos los campos y esto lo puede hacer enviando el mensaje Request_Validate al DDO que va a llevar a cabo la grabacin. Normalmente todos los campos de todas las tablas que participan en una grabacin sern validados. Esto incluye campos que no tengan representacin visual en la vista en curso y todos los campos en todas las tablas ascendentes (ejemplo: en una jerarqua nieto-padre-abuelo, nos referimos a las tablas padre y abuelo en relacin al nieto). En casi todos los casos, se desea este nivel de proteccin de datos, y es potente caracterstica del Diccionario de Datos. Tambin en casos infrecuentes puede seleccionar niveles inferiores de proteccin de validaciones. El Validate_Foreign_File_State de propiedad determina si la validacin de campo se debe aplicar a tablas forneas (padre). Normalmente, querr este nivel de validacin por lo que el valor por defecto es verdadero. Configurar que su valor sea falso pasar por alto la validacin de campo cuando la tabla sea usada como una tabla padre en una estructura de DDO. Esto har que se supriman las validaciones en todas las tablas ascendentes. Poner esta propiedad fuera de los valores por defecto ignora la validacin de campo y compromete la integridad de datos. Solamente deben ser usados bajo circunstancias cuidadosamente controladas. No use esta propiedad cuando busque soluciones rpidas para el diseo de base de datos. Las reglas especiales de validacin condicionales pueden ser programadas directamente en sus rutinas de validacin. Por ejemplo, podra desarrollar una rutina de validacin que solamente aplicase una validacin de campo a nuevos registros (verificar el estado con la propiedad de HasRecord del registro) o bien, podra crear rutinas de validacin que pasasen por alto ciertos campos de forma selectiva cuando son forneas (la variable global de tipo Entero_Integer_Operation_Origin nos dice que DDO empez la grabacin). En vez de romper una regla, intente definir este cambio de regla como parte de su conjunto de reglas. Al final, tendr una mejor solucin en todos los aspectos.
Pgina 36 de 92
Definir los atributos de campo de diccionario de datos

Los atributos de campo permiten que defina la informacin extensiva sobre cada campo en su tabla. Cuando desarrolle su aplicacin, esta informacin ser usada por el Studio y sus asistentes (wizards) para automatizar gran parte del proceso de desarrollo. Cuando ejecuten su programa, esta informacin ser usada para ayudar con la navegacin, ayudar con la entrada de datos, proporcionar ayuda al contexto, proveer las validaciones Fijar los atributos de campo consiste en definirlos para: Las opciones de campo (Field Options). Las validaciones de campo (Field Validation). Las apariencias de campo (Field Appearences). Mtodos de entrada y salida de campo (Field Entry and Exit Methods). El incremento automtico de campos (Auto-Increment Fields). Las listas de consultas de campo (Field Lookup Lists).
Opciones de campo (Field Options)

La propiedad Field_Options se emplea para fijar varias alternativas para cualquier campo. Estas alternativas condicionan la variedad de atributos incluyendo encontrar los comportamientos (ej. Bsqueda automtica auto-find, bsqueda requerida find-required), los comportamientos de entrada de datos (ej. Siempre maysculas Capslock) y comportamientos de actualizacin (NoPut, Force-Put). Estas opciones se definen con varias constantes de DD y se enumeran a continuacin. Las alternativas mostradas abajo con un asterisco (*) son opciones de Bsqueda y pueden usarse solamente sobre campos indexados. Las otras opciones pueden ser empleadas con cualquier campo, con la excepcin de campos extensos (Extended Fields).
Auto-Find Auto-Find GE Uppercase Display-Only Find-Required Force-Put
DD_AutoFind * DD_AutoFind_GE * DD_CapsLock DD_DisplayOnly DD_FindReq * DD_ForcePut
Pgina 37 de 92

No-Enter No-Put Retain Retain-All Required Skip-Found Zero-Suppress DD_NoEnter DD_NoPut DD_Retain DD_RetainAll DD_Required DD_SkipFound DD_Zero_Suppress
Por ejemplo, podra definir que un campo fuera Not-Put, Auto-Find y CAPSLOCK fijando las siguientes propiedades:
Field_Options field Customer.Id to DD_NoPut Set Field_Options field Customer.Id to DD_AutoFind Set Field_Options field Customer.Id to DD_CapsLock Debido a que a menudo hay opciones mltiples que deben ser aplicadas al mismo campo, se le permite combinar mltiples opciones en una sola lnea de la siguiente manera:
Set Field_Options field Customer.Id to DD_NoPut DD_AutoFind DD_CapsLock Field_Options puede ser fijado y modificado a nivel de Objeto de DD (DDO). Cuando lo use a nivel de objeto, no podr usar el mensaje de Field_Options. En vez de esto podr usar Field_Option (fjese que va en singular), Field_Option_Clear y Field_Option_Toggle. Para ms informacin vea Cambiar propiedades de campo dentro de DDO.
Set Field_Option field Customer.State to DD_Retain Set Field_Option_Clear field Customer.State to DD_Retain Set Field_Option_Toggle field Customer.State to DD_Retain
Bsqueda automtica (DD_AutoFind)

Set Field_Options field Customer.Id to DD_AutoFind DD_AutoFind ejecuta una bsqueda automtica por el ndice principal (Main Index) del campo. Esta opcin no funciona en un campo que no tenga ndice principal.
Pgina 38 de 92

Si se encuentra un registro cuyo valor en el ndice principal concuerda exactamente con los valores de los Forms de entrada, se muestran los datos del registro. Si no se encuentra ningn registro, el cursor sale del Form de manera normal y no se mueve ningn registro al Buffer. No se declarar ningn error. Generalmente pondra esta opcin en cada campo clave en su base de datos. Si desea buscar por un ndice que no sea nico, emplee Auto-Find GE. Cuando desee buscar un registro por un ndice multisegmento, ponga DD_AutoFind en el ltimo campo que participe en el ndice. Si lo usa conjuntamente con Find_Required, Auto-Find exigir al usuario que introduzca una clave que exista antes de continuar.
Bsqueda automtica GE (DD_AutoFind_GE)

Set Field_Options field Customer.Id to DD_AutoFind_GE DD_AutoFind_GE lleva a cabo una bsqueda GE (mayor o igual a) por el ndice principal de campo al salir del Form de entrada del campo. Esta alternativa no funciona en un campo que no tenga un ndice principal. Si se encuentra un registro cuyo valor en el ndice principal concuerda exactamente con los valores de los Forms de entrada, se muestran los datos del registro. Si no se encuentra ningn registro igual al que se est buscando, se busca el siguiente por ese ndice y ese es el que se muestra. Auto-Find GE es til para encontrar por anotaciones parciales a elementos o en ndices con varios segmentos por claves del primer(os) segmento(s) en vez de todos ellos. Todos los ndices no nicos son multi-segmento (estando compuestos, por lo menos, de un campo y del campo de identificacin del registro). Puede usar AutoFind-GE en cualquier campo tanto si el ndice principal de campo es nico o si no lo es. Si est empleando Auto-Find GE en un ndice multi-segmento, ponga la opcin de DD_AutoFind_GE en el ltimo campo del ndice para el que desee introducir valores. Si cualquier campo que se antepone a uno con la alternativa de DD_AutoFind_GE en el ndice, carece de un valor de entrada en su Form, el valor de ese campo ser considerado vaco para los propsitos de la bsqueda. El registro encontrado ser uno cuyo valor para el primero en ese campo sea el ms bajo en el ndice Si quiere ejecutar una bsqueda automtica para encontrar una coincidencia exacta igual a (EQ) usa la opcin AUTO_FIND. Auto-Find GE encontrar siempre un registro, a menos que la tabla est vaca.
UPPERCASE (DD_CapsLock)
Set Field_Options field Customer.Id to DD_CapsLock
Pgina 39 de 92

DD_CapsLock cambia, automticamente, cualquier carcter que la entrada haya relacionado con el campo (en letras maysculas). No tiene efecto en los caracteres no-alfabticos. Esto garantiza que todos ingresen datos en la entrada con letras maysculas.
Fuerza de escribir (DD_ForcePut)
Set Field_Options field Customer.Id to DD_ForcePut DD_ForcePut fuerza a los contenidos de los Forms de entrada de datos a que pongan en el buffer de registro de la tabla antes de una grabacin incluso si no se ha hecho ningn cambio. Normalmente los contenidos de los Forms de entrada de datos, solo se ponen en El buffer si han sido cambiados en relacin a lo que fue mostrado originalmente desde el disco.
No-Enter (DD_NoEnter)
Set Field_Options field Customer.Id to DD_NoEnter DD_NoEnter evita la introduccin de datos a travs de cualquier Form asociado con el campo. Nota especial: La opcin Skip-Found (DD_SkipFound) tiene un efecto similar, excepto que permite que el cursor vaya a ese elemento si no se encontr ningn registro. No-Enter pasa por alto el Form sin considerar si se encuentra un registro. La alternativa DD_DisplayOnly es una combinacin de DD_NoEnter y DD_NoPut. Aunque los datos no puedan ser introducidos desde el teclado a un Form controlado por No-Enter. Estos pueden ser movidos al Form bajo el control del programa. Esos sern pasados al buffer y grabados, cosa que no se hace con las opciones de campo Display_Only y No_Put.
No-Put (DD_NoPut)
Set Field_Options field Customer.Id to DD_NoPut DD_NoPut no permite que los datos se pasen de los Forms de entrada al buffer de registro del campo, incluso si se han introducido datos nuevos va teclado. No-Put es til para permitir que se introduzcan datos en un Form donde no desee permitir que se modifique el campo. Use la opcin No-Put cuando quiera impedir que los usuarios cambien los datos. La alternativa DD_DisplayOnly es una combinacin de DD_NoEnter y DD_NoPut.
Pgina 40 de 92

Display_Only (DD_DisplayOnly)
Set Field_Options field Customer.Id to DD_DisplayOnly DD_DisplayOnly hace que el cursor pase por alto el Form de entrada de datos asociado con este campo e impide que se modifique cualquier dato. El Form se mostrar como desactivado. DD_DisplayOnly es equivalente a la combinacin de DD_NoEnter y DD_NoPut.
// This is the same as DD_DisplayOnly Set Field_Options field Customer.Id to DD_NoEnter DD_NoPut
Retain(DD_Retain)
Set Field_Options field Customer.Id to DD_Retain DD_Retain (mantener) evita que los Forms de entrada de datos asociados al campo se limpien (vacen) cuando el usuario inicia una operacin que normalmente limpiara todos los Forms de una vista. Si el usuario inicia la operacin clear-all, entonces no se conservar absolutamente ningn dato. Es algo que habitualmente no se puede aplicar a todos los objetos en todas las vistas que usen una clase DD en concreto. En vez de eso, la opcin de mantener (Retain) se debera basar en los requisitos especficos de entrada de datos de una vista. Por lo tanto se espera que Retain sea aplicado en nivel de objeto de DD y no como parte de la definicin de clase.
Retain-All (DD_RetainAll)
Set Field_Options field Customer.Id to DD_RetainAll DD_RetainAll impide que los Forms de entrada de datos asociados con el campo se limpien (vacen). Aunque los usuarios no puedan limpiar el Form, la entrada de datos s podra hacerlo manualmente borrando carcter a carcter presionando la tecla Limpiar. Es algo que habitualmente no se puede aplicar a todos los objetos en todas las vistas que usen una clase DD en concreto. En vez de eso, la opcin de mantener (Retain) se debera basar en los requisitos especficos de entrada de datos de una vista. Por lo tanto se espera que Retain sea aplicado en nivel de objeto de DD y no como parte de la definicin de clase.
Pgina 41 de 92

Skip-Found (DD_SkipFound)
Set Field_Options field Customer.Id to DD_SkipFound DD_SkipFound previene la entrada de datos en los Forms de entrada de datos del campo si el buffer para la tabla tiene un registro activo. DD_NoEnter es una opcin de campo similar. Sin embargo, pasa por alto el Form de base de datos en todos los casos, sin considerar si hay un registro activo en el buffer.
Zero-Suppress (DD_Zero_Suppress)
Set Field_Options field Customer.Id to DD_Zero_Suppress DD_Zero_Suppress limpia el Form de entrada de datos del campo si este es numrico con valor cero (0). DD_Zero_Suppress parecer no funcionar en donde haya un valor absoluto pequeo en un Form. Por ejemplo, si un Form especifica valores enteros de visualizacin y un valor de campo inferior a 1 (por ejemplo 0,5) se mostrar cero en el Form. Solamente un valor que sea realmente cero (0) ser mostrado como espacios en blanco.
Require (DD_Required)
Set Field_Options field Customer.Id to DD_Required DD_Required se asegura de que se introduzcan datos en un campo. Cualquier carcter o caracteres que se introduzcan en el Form de entrada de datos permitirn que el cursor se mueva al siguiente Form. Este requisito se aplicar tambin durante la validacin de grabacin.
Find-Required (DD_FindReq)
Set Field_Options field Customer.Id to DD_FindReq DD_FindReq impide que el cursor se vaya al siguiente Form de entrada de datos hasta que se encuentre un registro vlido del campo asociado al Form. Una bsqueda fallida causa un Error 90 (por favor introduzca un registro vlido). Find required no tiene ningn efecto si un registro activo para la tabla ya est en la vista.
Pgina 42 de 92

Normalmente aplicara Find Required como una opcin de campo forneo (Foreing-Field) en una tabla padre para asegurarse que se encuentra un registro relacionado antes de que ocurra una grabacin en la tabla hijo. Una opcin de Auto-Find en el campo con Find Required intentar encontrar el registro automticamente cuando un usuario intente mover el cursor fuera del Form. Si la bsqueda automtica tiene xito el cursor continuar. Si no se encuentra el registro ocurrir el Error 90 (limpia el Form de entrada de datos del campo si este es numrico con valor cero). Find Required con Auto-Find GE es innecesario. Auto Find GE siempre encuentra un registro en una tabla que no est vaca. Este requisito de bsqueda se aplicar tambin durante la validacin de grabacin.
Limpiar opciones de campo

Se soportan mensajes opcionales para permitir que se limpien o alternen ciertas opciones de elementos: Field_Option_Clear (y File_Field_Option_Clear) limpia las opciones de campo pasadas por este mensaje
Set Field_Option_Clear Field Customer.Name to DD_Retain Field_Option_Toggle (and File_Field_Option_Toggle) alternan las opciones de campo pasadas por este mensaje
Set Field_Option_Toggle Field Customer.Name to DD_Retain Estos mensajes rara vez son usados en clases de Diccionario de Datos. Cuando sean usados se emplearn en los DDOs para controlar dinmicamente una vista de entrada de datos. Vea Cambiar propiedades de campo con DDOs para ms informacin.
Definir atributos de campo de Diccionario de Datos.
Validaciones de campo (Field Validations)

Las validaciones de campo se usan para verificar que un valor de campo combine con un valor vlido. Se puede definir uno de los cuatro tipos de validaciones de campo: Casilla de verificacin (Checkbox): debe ser uno de dos valores, generalmente, verdadero o falso. Rangos (Range): el valor introducido debe de estar dentro de un rango de nmeros o fechas.
Pgina 43 de 92

Verificacin (Check): el valor introducido debe encajar match con un elemento de una cadena de verificacin. Una cadena de valores vlidos separados por el carcter "|". Tabla de validacin: el valor introducido debe encajar match con un valor de un objeto de una tabla de validacin. Una tabla de validacin especial llamada tabla de validacin de clave (Code Validation Table) provee una manera fcil de atribuir un juego de las claves y descripciones vlidas a cualquier campo.
Adems, para cualquier campo puede definir un mtodo personalizado de validacin (Field Validation Method). Este mtodo, una funcin, se asigna a un campo fijando el mensaje de validacin de campo (Field Validation Message). Esta funcin se llama durante la validacin. Si se detecta un error, la funcin debe generar uno y devolver un valor distinto de cero. Esta funcin permite que cree cualquier tipo de regla de validacin que necesite. La validacin de campo ocurre durante la navegacin hacia delante (Forward Navigations) y las paradas. Usar validaciones de campo asegura que los datos que se estn grabando en su base de datos son vlidos.
Casilla de verificacin (Checkbox)

Set Field_Checkbox_Values field Customer.Status to "A" "I" El mensaje Field_Checkbox_Values marca el campo para que se use con una casilla de verificacin (Checkbox). Un campo de casilla de verificacin puede almacenar uno de dos valores, un valor verdadero y uno falso. Si el campo se representa con una casilla de verificacin (dbCheckbox), el control estar marcado cuando el campo con el que el valor se compare sea verdadero. Estar desmarcado cuando el campo con el que el valor se compare sea falso. Si el campo es representado por un control tipo Form (dbForm) la entrada de datos estar restringido al valor verdadero o al valor falso. Cuando hay un error de validacin, el nmero de error y el texto especificado para el campo en la propiedad de Field_Error se usan para informar del error. Si no se define ningn texto, se informa con el texto de error estndar.
Rangos (Range)
Set Field_Value_Range.field Customer.discount to 0 60 El mtodo de Field_Value_Range permite definir un valor mnimo y mximo para el campo. El campo y sus rangos deben ser numricos o fechas. El valor Desde debe ser inferior al del Hasta. La validacin se lleva a cabo despus de que el usuario haya introducido los datos en el Form de entrada de datos del campo. Si falla la validacin, entonces el usuario no podr dejar el Form. (El usuario todava puede salir del Form haciendo clic con el ratn en otro lugar de la pantalla).
Pgina 44 de 92

Cuando ocurre un error de validacin, el nmero de error y el texto especificado para el campo en la propiedad de Field_Error se emplean para informar sobre el mismo. Si no se define ningn texto, se informa con el texto de error estndar. La validacin tambin se lleva a cabo cuando se graba un registro. Si falla la validacin, se suspende la grabacin.
Verificacin (Check)
Set Field_Value_Check field Customer.region to " N|S|E|W" El mensaje de Field_Value_Check se emplea cuando la lista de valores vlidos est limitada a un juego esttico y pequeo de valores. Estas muestras estn identificadas en una cadena de comprobacin (Check String). Esto consta de una lista de valores vlidos separados por el Smbolo "|". Por ejemplo, para posibles valores vlidos A, B, C, se usara la cadena A|B|C, mientras que para valores vlidos Po, Ou, Lu se representara con la cadena Po|Ou|Lu La validacin se lleva a cabo despus de que el usuario haya introducido los datos en el Form de entrada de datos del campo. Si falla la validacin, entonces el usuario no podr dejar el Form. (El usuario todava puede salir del Form haciendo clic con el ratn en otro lugar de la pantalla). Adems de usarse para validar, estos valores tambin pueden usarse con elementos de entrada Combo-Box. Si se asigna un dbComboForm a un campo que usa valores de verificacin (Check), cada valor del String de verificacin ser cargado en la lista de combo (Combo-List).
Set Field_Value_Check field Customer.state to "Po|Ou|Lu|SA" Quizs el ejemplo de Customer.state no sea probablemente una buena muestra de de este mtodo de validacin. Aadir nuevas provincias a esta lista requiere cambios de programa, y el String puede ponerse demasiado grande para ser prctico. En ese caso, querr usar una tabla de validacin (Validation Table). Cuando hay un error de validacin, el nmero de error y el texto especificado para el campo en la propiedad de Field_Error se usan para informar del error. Si no se define ningn texto, se informa con el texto de error estndar. La validacin de verificacin (Check) es limitada. Una manera ms flexible y reutilizable de especificar una lista de entradas vlidas es usar una Tabla de Validacin.
Tablas de validacin (Validation Tables)

Set Field_Value_Table Field Customer.Status to oStatusTable Si un campo tiene que ser validado contra uno de dos valores, con un conjunto limitado de valores, o con un rango de valores, puede usar la casilla de verificacin (Checkbox), Rangos (Rango) o Validaciones (Check). En muchos casos descubrir que estas clases de validaciones
Pgina 45 de 92

son demasiado limitadas para sus necesidades. En ese caso, puede usar tablas de validacin de campo. Usar una tabla de validacin de campo tiene las siguientes ventajas: Especificar un nmero ms grande de valores vlidos de los que puede encajar en una cadena de valores vlidos. Especificar y mostrar una descripcin para cada valor. Puede mantener actualizada su lista de valores (los valores no tienen que ser codificados directamente en su programa). Puede hacer las elecciones de lista opcionales (puede sugerir una lista de valores durante la introduccin de datos pero a los usuarios no se les exiges hacer una seleccin de la lista).
Cuando ocurre un error de validacin, el nmero de error y el texto especfico para el campo en la propiedad de Field_Error se emplean para informar sobre un error. Si no se define ningn texto, se informar con un texto estndar. El uso de tablas de validacin da una flexibilidad tremenda. Ms adelante se hablar con detalle de cmo usar tablas de validacin. Por ahora abordaremos el tema de las clases primarias de Tablas de Validacin:
Tabla de validacin (Validation Table)

Esta clase permite que mantenga actualizada una lista de valores vlidos.
Object oStatusTable is a ValidationTable Procedure Fill_List Send add_table_value "O" Send add_table_value "C" Send add_table_value D End_Procedure End_Object
Descripcin de validacin de tabla (Description Validation Table)

Esta clase permite que mantenga actualizada una lista de valores vlidos y sus descripciones asociadas. Object oStatusTable is a DescriptionValidationTable Set List_Title to "Customer Status" Procedure Fill_List Send add_table_value O "Opened Send add_table_value C Closed Send add_table_value D "Flagged for Deletion End_Procedure End_Object
Pgina 46 de 92
Tabla de validacin de archivo (File Validation Table)

Esta clase le permite mantener actualizada una lista de valores y descripciones que puede ser fcilmente cargado desde una tabla Visual DataFlex especfica. Object StatusTable is a FileValidationTable Set Main_File to CustStat.File_Number End_Object
Tablas de validaciones de cdigo (Code Validation Table)

Esta clase permite que cargue sus valores de datos y descripcin de la lista de claves de Visual DataFlex (Visual DataFlex Code List)
Object oStatusTable is a CodeValidationTable Set Type_Value to "Status" End_Object Cualquiera de las tablas de validacin de arriba puede ser conectada a un campo con el mensaje de Field_Value_Table en un Diccionario de Datos.
Set Field_Value_Table Field Customer.Status to oStatusTable
Mtodos de validacin de campo (File Validation Methods)

Set Field_Validate_msg field employee.pay_type to get_valid_pay_type La propiedad de Field_Validate_msg le deja asignar el mensaje a ser enviado cuando un campo debe ser validado. Este mensaje ser el mensaje Id de una funcin y se llama cuando el programa necesita una validacin. Este mtodo de validacin se usa cuando tiene que llevar a cabo validaciones complejas que pueden ser expresadas solamente con cdigo. Debido a que es un proceso muy abierto, puede hacer prcticamente cualquier cosa. Si el valor es vlido, la funcin debe devolver un cero. Si el valor no es vlido, la funcin debe generar un error y devolver un valor distinto de cero. Este mtodo de validacin puede usarse en conjunto con otras tcnicas de validacin (casilla de verificacin-Checkbox; Rangos-Range; Verificacin-Check o Tabla de Validacin-Table Validation) o como una sustitucin de ellos. Deber crear la funcin(s) de validacin (s). Esta funcin pasa el nmero de campo y el valor del campo. La funcin puede usar estos valores cuando sea conveniente. Para este propsito, el valor de cualquier otro campo en el Diccionario de Datos puede ser obtenido mediante la propiedad de
Pgina 47 de 92

Field_Current_Value. Es importante notar que la rutina de validacin nunca necesitar acceder a un valor de un DEO. La informacin necesaria deber poder ser encontrada en el DDO o en uno de los DDOs conectados con ella. Por ejemplo, si tiene la siguiente funcin:
Function ValidateCredit Integer iField Number nValue ; Returns Boolean Boolean bErr String sCustRating // get the customer rating for this customer from DD buffer Get Field_Current_Value field Customer.Rating to sCustRating // If customer Rating is A1 their limit is 5000 If (sCustRating = "A1" and nValue> 5000) Begin Error DFERR_OPERATOR "Credit limit may not exceed $5000" Move True To bErr End Function_Return bErr End_Function
Para usar esta funcin en el campo Credit_Limit de una tabla, debe establecer el mtodo de validacin (Field_Validate_msg) al Handle Name de la funcin. El Handle Name de una funcin es el nombre de la funcin con el prefijo Get (por ejemplo: Get_ValidateCredit). Set Field_Validate_msg field Customer. Credit_Limit to get_ValidateCredit El prototipo de declaracin para un mtodo de validacin tiene la siguiente forma. Function_function_name integer iField type CurrentValue returns integer Dnde: Function_name es el nombre de la funcin de validacin; iField es el nmero de campo del campo que envi function_name. El nmero de campo puede ser usado para recuperar cualquier informacin sobre el campo y TypeCurrentValue es el tipo de datos y el valor actual del campo que envi function_name.
Esto le permite escribir funciones de validacin de mtodos generalizados que pueden ser usados por otros campos y tablas.
Errores de validacin de campo (Field Validation Errors)

Set Field_Error field Customer.Credit_Limit to 200 Not a legal number"
Pgina 48 de 92

El mtodo Field_Error permite definir un nmero de error especfico y enviar un mensaje siempre que la validacin falle para el campo. Esto quiere decir que cada campo puede tener su propio mensaje de error de validacin especfico. El error es lanzado cuando una de las siguientes pruebas de validacin falla: casilla de verificacin-Checkbox; Rangos-Range; Verificacin-Check o Tabla de Validacin-Table Validation. Los mtodos de validacin deben tener sus propios textos de error codificados dentro de la funcin.
Definir los atributos de campo de Diccionario de Datos.
Aspecto del campo

Mscaras (Masks)
Set Field_Mask Field Orderhea.Order_Date to "mm - dd - yyyy" Set Field_Mask_Type Field Orderhea.Order_Date to MASK_DATE_WINDOW Las mscaras se emplean en las aplicaciones Windows de Visual DataFlex para: Restringir la entrada de datos en un campo a un patrn definido de nmeros, letras o caracteres de puntuacin. Proveer la visualizacin de los datos de un campo de acuerdo a formatos y patrones predefinidos. Por ejemplo, es posible mostrar valores de fecha con las abreviaturas como das de la semana o meses del ao. La traduccin de nmeros a nombres es sensible a la Configuracin Regional de Windows
Las mscaras no son la validacin y no deben ser usadas como una tcnica de validacin. Las mscaras se definen poniendo dos propiedades de campo: Field_Mask_Type y Field_Mask. Las mscaras se comentan con ms detalle en Mscaras en las aplicaciones de Windows.
Etiquetas (Labels)
Set Field_Label_Long Field Orderhea.Terms To "Terms of Payment" Set Field_Label_Short Field Orderhea. Terms To "Terms" Se pueden asignar etiquetas largas y cortas a cada campo. Las etiquetas de campo largas y cortas se definen usando las propiedades de Field_Label_Long y Field_Label_Short. Cuando obtenga el valor de una etiqueta deber usar la funcin Field_Label.
Pgina 49 de 92

Get Field_Label Field DD_LABEL_SHORT to sHeaderName Get Field_Label Field DD_LABEL_LONG to sLabel La funcin Field_Label (y File_Field_Label) nos facilita flexibilidad adicional en determinar el valor de una etiqueta. Si se pide el valor de la etiqueta larga y no se ha asignado el nombre de etiqueta larga, se obtiene el nombre del campo. Si se pide el valor de la etiqueta corta y no se ha asignado el nombre de etiqueta corta, se obtiene el nombre de etiqueta largo.
Se aplica la misma lgica cuando el Studio o los asistentes (Wizards) se usan para disear vistas e informes. El Studio usar la etiqueta larga al crear controles de tipo Form (por ejemplo., DbForm, dbComboForm). Sin embargo usa las etiquetas cortas al crear controles de estilo de columna (por ejemplo., DbGrid).
Ayuda de estado (Status Help)

Set Status_Help field Cust.Status to "Customer is (A) ctive or (I) nactive" Status_Help define una lnea de texto de ayuda para el campo. Los objetos de entrada la usan para mostrar la ayuda en la barra de estado. Cuando el usuario cambia el cursor, un objeto de entrada de datos muestra la ayuda Status Help en la barra de estado. Introduzca el texto que ayude al usuario con informacin sobre el campo que va a introducir.
Controles de ventanas (Windows Controls)

Set Field_Class_Name field Cust.Address to "cDbAddressForm" Field_Class_Name asigna el nombre de clase de un control especfico a cada campo. Por defecto, Studio usar esta informacin para determinar la clase del control que se crea siempre que el campo sea arrastrado en un componente. Este ajuste no evita que elija una clase de control diferente para el campo de una forma explcita en el Studio, o para cambiar la clase del control de una forma individual; es solamente el valor por defecto. Si deja este espacio en blanco, el Studio determinar el mejor control para usar para el campo. El Studio hace un buen trabajo al asignar el control correcto as que esta propiedad se dejar, generalmente, vaca. Puede asignar cualquier nombre de clase en este Form. Si pone en el nombre de una clase no estndar, entonces la clase debe ser registrada correctamente en Studio antes de que pueda ser usado.
Pgina 50 de 92
Mtodos de entrada y salida

Las propiedades de Field_Entry_msg y Field_Exit_msg son similares al Field_Validate_msg y son enviadas siempre que el cursor entre o salga de un elemento conectado con un campo. Creara los procedimientos y luego atribuira los nombres de procedimiento (procedure) a las propiedades de campo. Cuando se llaman se pasa el nmero de campo y el valor del campo. Al procedimiento (procedure) mientras devuelva un valor distinto a cero se podra parar la navegacin, esto sera un uso anormal o poco habitual. Estos procedimientos se emplean, generalmente, para manejar procesos antes de entrar y despus de salir.
Mtodo de entrada
Set Field_Entry msg Field Customer.State To EntryCustomerState Field_Entry_msg permite que especifique el nombre de un mtodo que se ejecuta siempre que el cursor se mueve un Form de entrada de datos conectado al campo. El mtodo de entrada, un procedimiento, puede ser programado para llevar a cabo cualquier accin. Podr usarlo para mostrar informacin especial o valores por defecto cada vez que el cursor vaya al campo. En Visual DataFlex, los procedimientos pueden devolver un valor entero. En el caso de un mtodo de entrada (Entry method), si se devuelve un valor distinto de cero, se aborta la entrada del cursor al Form. Usar los mtodos de entrada para controlar la navegacin es muy desaconsejable. El mtodo de entrada debe ser un procedimiento de la clase de Diccionario de Datos de la tabla. Por ejemplo si tiene el siguiente procedimiento:
Procedure EntryOrderDate Interger iField Date dDate // Add a default date if the fields is blank Boolean bChanged Get Field_Changed_State iField to bChanged If (not (bChanged) AND dDate = 0) Begin SysDate dDate Set Field_Default_Value iField to dDate End End_Procedure Para usar este procedimiento en un campo fecha de una tabla, pondra el mtodo de entrada de campo a EntryOrderDate. Estara asignando el manejador de mtodo msg_EntryOrderDate pero si se omite el prefijo "msg" este ser proporcionado automticamente.
Pgina 51 de 92
Set Field_Entry_msg Field Orderhea.Order_Date To EntryOrderDate El prototipo de declaracin para un mtodo de entrada tiene el siguiente formato general. procedure procedureName integer iField type currentValue Dnde: procedureName es el nombre del procedimiento; iField es el nmero de campo del campo que envi procedureName. El nmero de campo puede usarse para obtener cualquier informacin sobre el campo. Type y currentValue son el tipo y el valor actual del campo que envi procedureName.
Los parmetros que se pasan al mtodo de entrada permiten que escriba procedimientos generalizados que pueden ser reutilizados en otros campos y tablas.
Mtodo de salida
Set Field_Exit_msg Field Customer.Zip To ExitAdjustZip Field_Exit_msg permite que especifique el nombre de un mtodo que se ejecute siempre que el cursor se va de un Form de entrada de datos conectado al campo. El mtodo de salida, un procedimiento, puede ser programado para llevar a cabo cualquier accin. Por ejemplo, podra usarlo para ajustar valores de algunos datos calculados que estn en funcin del valor del campo introducido. En Visual DataFlex, los procedimientos pueden devolver un valor entero. En el caso de un mtodo de salida, si se devuelve un valor distinto de cero se aborta la accin de salir del Form de entrada de datos. No se recomienda utilizar este evento para controlar la navegacin. El mtodo de salida debe ser un procedimiento de clase de Diccionario de Datos de la tabla. Por ejemplo si tiene el siguiente procedimiento:
Procedure AdjustDisplayTotal Interger iField Interger iValue // This updates the extender Price field, which will update any // display balances.This is only done for display purposes.The // actual amount is updated to the field during the save. Interger iQty Number nAmnt Get Field_Current_Value Field Orderdtl. Qty_Ordered to iQty Get Field_Current_Value Field Orderdtl.Price to nAmnt Set Field_Current_Value Field Orderdtl. Extended_Price to (nAmnt * iQty) // note we set value, but not changed state! End_Procedure
Pgina 52 de 92

Para usar este procedimiento sobre el campo apropiado de una tabla, pondra el mtodo de entrada del campo a AdjustDisplayTotal. Estara asignando el manejador de mtodo msg_AdjustDisplayTotal pero si se omite el prefijo msg este ser proporcionado automticamente.
Set Field_Exit_msg Field Orderdtl.Qty_Ordered to Adjust_Display_Total El prototipo de declaracin para un mtodo de salida tiene el siguiente formato general.
procedure procedureName integer iField type currentValue Dnde: procedureName es el nombre del procedimiento; iField es el nmero del campo que envi procedureName. El nmero de campo puede usarse para obtener cualquier informacin sobre el campo. Type y currentValue son el tipo y el valor actual del campo que envi procedureName.
Los parmetros que se pasan al mtodo de salida permiten que escriba procedimientos generalizados que pueden ser reutilizados en otros campos y tablas.
Autoincremento del campo

Cada registro en una tabla debe contener un campo o juego de campos que proporcionen una identificacin nica al registro. Esto sera la clave primaria. En algunos casos, el valor de la clave primaria debe ser introducido manualmente por el operador (Ej. Introducir una identificacin de cadena nica como parte de la entrada de datos). En algunos casos, la base de datos suministrar la calve primaria automticamente al grabar el registro. En otros casos, el Diccionario de Datos debe suministrar esta identidad nica cuando se grabe el registro por primera vez. El autoincremento (Auto-Incremento) del Diccionario de Datos nos da esta funcionalidad asignando nmeros automticamente y de forma secuencial a cada nuevo registro. Para que el Diccionario de Datos sepa cul es el siguiente nmero a un nuevo registro debemos almacenar el ltimo nmero asignado en una tabla externa. Para crear un campo autoincremento, necesitar definir en el Diccionario de Datos la tabla externa y el campo en esa tabla que se va a usar para almacenar ese nmero as como el campo ID (clave primaria) en su Diccionario de Datos. Para facilitar esta operacin existe un comando llamado Define_Auto_Increment
Define_Auto_Increment ordsys.last_cust_num to Customer.cust_number
Pgina 53 de 92

En este ejemplo, el campo Ordesys.Last_Cust_Num tabla sistema se designa para incrementar y suministrar un valor al campo cust_number de la tabla Customer. El autoincremento funcionar correctamente solo si la tabla externa es una tabla de sistema (un solo registro) o una Tabla Padre con la que est relacionada. Usar una tabla sistema si el identificador nico es de un solo segmento como muestra en el ejemplo anterior con cust_number. Si est usando un campo de una tabla sistema, tiene que registrar esta tabla como una tabla externa de forma que se bloquee correctamente durante operaciones de grabacin. Por ejemplo:
Define_Auto_Increment ordsys.last_cust_num to Customer.cust_number Send Add_System_File ordsys.last_cust_num DD_LOCK_ON_NEW_SAVE_DELETE Puede usar una tabla padre relacionada si su identificador (ID) nico es multi - segmento. Por ejemplo el ID de una estructura Cabecera-Detalle como en pedido-detalle pedido. Por ejemplo, el ID de una tabla de Detalle (Order-Detail) en una estructura Cabecera-Detalle (header-detail) podra ser el nmero del documento (Cabecera) y un nmero de orden de detalle asignado por una tabla sistema. Si el ltimo nmero de detalle de cada cabecera fuera almacenado en la tabla Cabecera (OrderHea.Last_Detail_Num) el campo de Autoincremento se definira como:
Define_Auto_Increment OrderHea.Last_Detail_Num to OrderDtl.Detail_Number Solamente puede asignar un autoincremento campo por DDO. Si intenta atribuir dos, entonces de autoincremento del primer campo ser ignorado. Si tiene que asignar campos de autoincremento adicional dentro de su Diccionario de Datos puede hacerlo fcilmente aadiendo un cdigo personalizado al evento de Creating del Diccionario de Datos.
Listas de consultas (Lookup lists)

Set Field_Prompt_Object field Customer.name to Cust_lkup Las listas de consulta se crean para poder buscar registros de una manera fcil en su aplicacin. Tpicamente cada tabla tendr al menos una lista de consulta relacionada con ella. Las columnas en esta lista de consulta contarn, a menudo, con los campos ms importantes de su tabla. Estos campos se ponen normalmente en un ndice y las listas de consulta se disean para dejar buscar registros fcilmente por cualquiera de esos ndices. Asignar campos en un Diccionario de Datos a una lista de consulta se hace fijando la propiedad de Field_Prompt_Object. Una vez asignadas, sus aplicaciones Windows fijarn esas listas de consulta a todos los objetos de introduccin de datos que usan ese campo de forma automtica.
Pgina 54 de 92

Habitualmente crear sus objetos de lista de consulta antes de que los asigne a un Field_Prompt_Object. Debe saber el nombre del objeto de la lista de consulta antes de asignarlo. Existen asistentes que le permiten crear sus listas de consultas y asignarlos a los campos de Diccionario de Datos apropiados en un solo paso. Si est usando uno de los tipos de validacin (casilla de verificacin, rango, tabla de verificacin o validacin) es capaz de suministrar una lista de consulta por defecto; lo hace si no tiene una asignada explcitamente. As que si asigna a un campo un Field_Prompt_Object, este se usar en vez de la lista suministrada para las validaciones extendidas.
Pgina 55 de 92
Definir atributos de campos forneos en Diccionario de Datos

Dentro de su DEO (Objeto de entrada de datos) el comando Entry_Item une una tabla y el valor del campo a un form o a una columna de una parrilla (grid). Esta tabla ser la tabla principal del Diccionario de Datos del DEO, o la tabla padre. Cuando se use como una tabla padre, el Entry_Item se considera conectado con un campo forneo. Es importante comprender el concepto de un campo forneo. El siguiente ejemplo muestra un Entry-Item que no es forneo seguido por uno que si lo es:
// Part of an order entry view // Object oOrderNumber is a dbForm Set Server to oOrderhea_DD Entry_Item Orderhea. Order_number //this is not a foreing field : Object oCustomerName is a dbForm Set Server to oOrderhea_DD Entry_Item Customer.Name/ this is a foreing field : Un ejemplo de un campo extranjero es el campo customer.Name cuando sale en un view del Order Entry. Esto es debido a que es la tabla Order-Header la que provee el servidor de Diccionario de Datos; la tabla cliente (customer) en este ejemplo es padre del Order-Header.
// Part of customer maintenance view // Object oCustomerName is a dbForm Set Server to oCustomer_DD Entry_Item Customer.Name// this is not a foreing field : Cuando el campo customer.Name sale en la vista del mantenimiento de clientes, no es un campo forneo porque en este caso la tabla del cliente provee el servidor de Diccionario de Datos. Cuando el nmero de la tabla (File-Number) de Entry_Item no es el mismo que el nmero de la tabla principal del Diccionario de Datos, la tabla debe ser un antepasado (padre, abuelo, etctera.). Si no lo es, probablemente, ha cometido un error. Los elementos de entrada de datos de tablas de ancestros (tablas padre, abuelo) se usan generalmente de forma diferente a la entrada de datos de la tabla principal. Cuando se introduce un registro nuevo en la principal, los registros de la tabla padre no se modifican. Su funcin es proporcionar valores de campo (nmero de cliente, forma de pago) en los que se basan las relaciones de la tabla principal a la tabla padre. Cuando se tiene que modificar la tabla padre
Pgina 56 de 92

(aadir, modificar, borrar) dicha modificacin se realiza en una vista diferente en la que la tabla (padre) es la tabla principal del DDO. Debido a esto, los campos forneos requieren, a menudo, ajustes de opcin de campo adicionales. Las opciones de campo forneos pueden ser atribuidos a campos individuales aunque esto raramente se hace ya que hay multitud de formas ms convenientes de hacerlo. Los campos forneos pueden ser divididos en tres categoras. stas son: Campos Clave (Key Field): es cualquier campo para el que la propiedad de Key_Field_State es verdadero (Clave primaria). Campo Indexado (Indexed Field): es cualquier campo que no es un campo clave y es un segmento en uno o ms de los ndices de la tabla. Campo por defecto (Default Field): es cualquier campo que no es un campo clave o un campo indexado.
Definiendo opciones de campo forneos para cada uno de estas categoras de campos (DD_KEYFIELD, DD_INDEXFIELD, DD_DEFAULT) proporciona a sus aplicaciones de introduccin de datos los elementos necesarios sin programacin adicional. Las propiedades de campo forneos se aaden cualquier propiedad de opcin regular de campo. Los siguientes ejemplos indican un uso tpico de opciones de campo forneas.
Set Field_Options field Customer.id to DD_NoPut DD_AutoFind DD_CapsLock Set Field_Options field Customer.balance_due to DD_DisplayOnly : // define default foreing field options Set Foreign_Field_Options DD_KEYFIELD to DD_FindReq Set Foreign_Field_Options DD_INDEXFIELD to DD_NoPut Set Foreign_Field_Options DD_DEFAULT to DD_DisplayOnly En este ejemplo, las opciones de campo regulan (campo no forneo) para Customer_ID sern No-Put, Auto-Find y Capslock. Sus opciones de campo forneo sern No-Put, Auto-Find, Capslock y puesto que es un campo clave, Find-Required. Todas las opciones de campo regulares se pueden asignar como opciones de campo forneos. En la prctica, las nicas opciones que probablemente vaya a poner son DD_NoPut, DD_NoEnter, DD_DisplayOnly, DD_AutoFind y DD_FindReq.
Campos Forneos clave

Un campo clave, DD_KEYFIELD, es cualquier campo para el que la propiedad de Key_Field_State es verdadera. Cuando se usen como campos forneos, probablemente, querr que estos campos sean Find-Required, Auto-Find y No-Put. Esto quiere decir que debe encontrarse un registro Padre antes de poder grabar el Hijo y que si se introduce un valor en el campo se producir una bsqueda automtica (Auto-Find) y no se podr modificar el valor de esta clave; eso si entra en un valor en el que el campo tiene un hallazgo automtico y no puede cambiar este valor de tecla. Los ajustes para este campo forneo sern:
Pgina 57 de 92

Set Foreign_Field_Options DD_KEYFIELD to DD_FindReq DD_AutoFind DD_NoPut A menudo las opciones de campo principales del campo de la clave primaria ya han especificado Auto-Find y No-Put y debido a que estas opciones estndar de campos se aaden a las opciones de campos forneos, nicamente necesitar ajustar:
Set Foreign_Field_Options DD_KEYFIELD to DD_FindReq
Definir Diccionario de Datos y atributos de campos forneos.
Campos Forneos indexados

Un campo indexado, DD_INDEXFIELD, es cualquier campo que no sea una clave primaria y que sea un segmento en uno o ms ndices de la tabla. Cuando se usa como campos forneos estos campos son generalmente accesibles (para que pueda llevar a cabo bsquedas manuales) pero definido como no modificable (No-Put) de forma que no pueda modificar y grabar su valor. Los ajustes para este campo forneo son:
Set Foreign_Field_Options DD_INDEXFIELD to DD_NoPut Alternativamente, puede incluso decidir el que no se soporte bsquedas en estos campos, en cuyo caso los ajustes para estos campos forneos sern:
Set Foreign_Field_Options DD_INDEXFIELD to DD_DisplayOnly
Campos Forneos por defecto

Un campo por defectos, DD_DEFAULT, es cualquier campo que no sea una clave primaria o un campo indexado. No querr poder cambiar este campo y debido a que no hay ndice relacionado con l, solamente lo podr ajustar a Display-Only. Los ajustes para este campo forneo sern:
Set Foreign_Field_Options DD_DEFAULT to DD_DisplayOnly
Pgina 58 de 92

Pgina 59 de 92
Definiendo Diccionarios de Datos de Padres, Hijos y relaciones externas

Los Diccionarios de Datos tienen que saber cmo modelar relaciones. Esto se obtiene:
Definiendo todas las tablas Padre con las que se est relacionando. Definiendo todas las tablas Hijo desde las que se est relacionando. Definiendo todas las tablas extra que puedan ser necesarias.
Una vez definido, sus objetos del Diccionario de Datos pueden usar esta informacin para verificar que las estructuras de DDO estn configurados adecuadamente para operaciones de grabacin y borrado.
Definiendo tablas padre Definiendo tablas hijo Requisitos para las grabaciones Requisitos para los borrados Cmo funcionan las estructuras de DDO de grabacin. Tablas sistema y tablas externas
Definiendo tablas Padre requeridas

Send Add_Server_File Customer.File_Number Un Diccionario de Datos tiene que estar al tanto de las tablas con las que est relacionado (tambin llamadas tablas padre). Identificando todas las tablas padre el Diccionario de Datos puede determinar si los DDOs (Objeto de Diccionario de Datos) han sido creados para todos estos padres y si esos DDOs padre estn apropiadamente conectados con el DDO principal. El DDO padre tambin tiene una lista de tablas padre y estos DDOs padre hacen lo mismo para asegurarse de que sus DDOs padre existen y de que estn apropiadamente conectados dentro de la estructura. Este proceso ocurre hacia la parte superior (hacia arriba) de la jerarqua de toda la base de datos.
Pgina 60 de 92

Propagando esta comprobacin hacia arriba se puede verificar si una estructura de Diccionario de Datos est completa. Si la estructura no est completa, ese DDO no podr grabar o borrar registros. La informacin de la tabla padre tambin es utilizada por el Studio y por varios asistentes para ayudarle a construir sus aplicaciones. Por lo tanto es importante que esta informacin sea mantenida correctamente en su clase de Diccionario de Datos. Se aaden tablas a la lista de tablas padre relacionadas con el mensaje Add_Server_File. Enve este mensaje a cada una de las tablas padre requerida.
Definir relaciones externas Padre-hijo de Diccionario de Datos.
Definiendo tablas Hijo requeridas

Send Add_Client_File Orderdtl.File_Number Un Diccionario de Datos tiene que estar al tanto de las tablas que estn relacionadas con l (tambin llamadas tablas Hijo). Identificando todas las tablas hijo el Diccionario de Datos puede determinar si los DDOs (Objetos de Diccionario de Datos) han sido creados para todos estos hijos y si esos DDOs hijo estn apropiadamente conectados con el DDO principal. El DDO hijo tambin tiene una lista de tablas hijo y estos DDOs hijo hacen lo mismo para asegurarse de que sus DDOs hijo existen y de que estn apropiadamente conectados dentro de la estructura. Este proceso ocurre hacia la parte inferior (hacia abajo) de la jerarqua de toda la base de datos. Propagando esta comprobacin hacia abajo se puede verificar si una estructura de Diccionario de Datos est completa. Si la estructura no est completa, ese DDO no podr borrar registros, puesto que no tiene los DDOs hijos para borrar en cascada los registros de las tablas hijos. La informacin de la tabla hijo tambin es utilizada por el Studio y por varios asistentes para ayudarle a construir sus aplicaciones. Por lo tanto es importante que esta informacin est mantenida correctamente en su clase de Diccionario de Datos. Se aaden tablas a la lista de tablas hijo relacionadas con el mensaje Add_Client_File. Enve este mensaje a cada una de las tabla hijo.
Pgina 61 de 92
Requisitos para grabar (save)

El requisito de estructura de DDO para una grabacin es simple. Para cada tabla padre definida en el DDO (con el mtodo Add_Server_File) debe estar representado como un DDO en la estructura de objetos y deben estar conectados apropiadamente (con la propiedad DDO_Server). Los siguientes fragmentos de cdigo muestran una clase de Diccionario de Datos y una estructura de DDO vlida que admitira grabaciones. Procedure Define_Fields Forward Send Define_Fields Set Main_File to Orderhea.File_Number : Send Add_Server_File Customer.File_Number Send Add_Server_File SalesP.File_Number Send Add_Client_File Orderdtl.File_Number End_Procedure : : Object oCustomer_DD is a Customer_DataDictionary End_Object // oCustomer_DD Object oSalesp_DD is a Salesp_DataDictionary End_Object // oSalesp_DD Object oOrderhea_DD is a Orderhea_DataDictionary Set DDO_Server to oCustomer_DD Set DDO_Server to oSalesp_DD End_Object // oOrderhea_DD Es un caso sencillo. Si cualquiera de los DDOs padre necesitase de padres, sus DDOs tambin tendran que estar presentes antes de permitir una grabacin. Por ejemplo, suponga que el Diccionario de Datos del cliente haya sido definido de la siguiente manera:
// Define_Fields in the customer DD class Procedure Define_Fields Forward Send Define_Fields set Main_File to Customer.File_Number : Send Add_Server_File Region.File_Number End_Procedure Ahora, la estructura del DDO de la lista de arriba ahora est incompleta. Est incompleta para Customer y por lo tanto est incompleta para OrderHea. No se admiten grabaciones en ninguno de los dos DDOs. Para que una estructura DDO sea vlida necesitara mostrarse as:
Pgina 62 de 92
Object oRegion_DD is a Region_DataDictionary End_Object // oCustomer_DD Object oCustomer_DD is a Customer_DataDictionary Set DDO_Server to oRegion_DD End_Object // oCustomer_DD Object oSalesp_DD is a Salesp_DataDictionary End_Object // oSalesp_DD Object oOrderhea_DD is a Orderhea_DataDictionary Set DDO_Server to oCustomer_DD Set DDO_Server to oSalesp_DD End_Object // oOrderhea_DD Note que Add_Server_File se emplea para definir una tabla padre requerida dentro de un Diccionario de Datos y que esto ocurre en el nivel de clase. El uso de DDO_Server crea la conexin en el nivel de objeto. Add_Server_File define el requisito y DDO_Server lo cumple.
Definir las relaciones externas Padre-hijo de Diccionario de Datos.
Requisitos para eliminar

El requisito de estructura de DDO para un borrado es algo ms complicado. Debido a que los borrados pueden modificar los registros padre, la estructura padre del DDO debe estar completa. Si desea admitir borrados en cascada (el borrado de registros hijo) entonces la estructura de su DDO debe contener tambin todos los DDOs hijos requeridos para poder llevar a cabo el borrado en cascada. Por ejemplo: Procedure Define_Fields Forward Send Define_Fields Set Main_File to Orderhea.File_Number : Send Add_Server_File Customer.File_Number Send Add_Server_File Sales.File_Number Send Add_Client_File Orderdtl.File_Number End_Procedure : : Object oCustomer_DD is a Customer_DataDictionary End_Object // oCustomer_DD Object oSalesp_DD is a Salesp_DataDictionary End_Object // oSalesp_DD
Pgina 63 de 92
Object oOrderhea_DD is a Orderhea_DataDictionary Set DDO_Server to oCustomer_DD Set DDO_Server to oSalesp_DD End_Object // oOrderhea_DD Object oOrderdtl_DD is a Orderdtl_DataDictionary Set DDO_Server to oOrderhea_DD End_Object // oOrderhea_DD Esta estructura de DDO ahora contiene los DDOs hijos requeridos y, por tanto, los borrados de los registros de OrderHea sern admitidos. Sin embargo estas estructuras, generalmente, no son tan simples. Si el DDO hijo (OrderDtl) contuviera tablas padre adicionales requeridas, entonces tienen que estar presentes esos DDOs hijos y sus respectivos DDOs padres. La estructura de DDO podra ser:
Object oVendor_DD is a Vendor_DataDictionary End_Object // oVendor_DD Object oInvt_DD is a Invt_DataDictionary Set DDO_Server to oVendor_DD End_Object // oInvt_DD Object oCustomer_DD is a Customer_DataDictionary End_Object // oCustomer_DD Object oSalesp_DD is a Salesp_DataDictionary End_Object // oSalesp_DD Object oOrderhea_DD is a Orderhea_DataDictionary Set DDO_Server to oCustomer_DD Set DDO_Server to oSalesp_DD End_Object // oOrderhea_DD Object oOrderdtl_DD is a Orderdtl_DataDictionary Set DDO_Server to oOrderhea_DD Set DDO_Server to oInvt_DD End_Object // oOrderdtl_DD
Pgina 64 de 92
Cmo trabaja la estructura de validacin DDO

Cuando se produce una solicitud para grabar o borrar en un Diccionario de Datos, se valida su estructura de objeto y se asegura que todos los padres e hijos DDOs estn presentes y conectados de forma apropiada. Dependiendo del tipo de operacin (grabar, borrado sin cascada, o borrado con cascada) se llevarn a cabo diferentes tipos de validaciones. Si la estructura de DDO en curso no est completa para la operacin especfica, se producir un error y la operacin se suspender. Verificar una estructura de DDO entera para una operacin en particular puede ser un proceso complicado. Mientras se suministre a cada clase de Diccionario de Datos con una lista exacta de tablas padre y tablas hijo requeridas, este proceso se tratar automticamente.
Modo de validacin
Set Validate_Save_Structure_Mode to DD_VALIDATE_STRUCTURE_ONCE Set Validate_Delete_Structure_Mode to DD_VALIDATE_STRUCTURE_ONCE Hay propiedades que le permitirn modificar la forma validar la estructura de grabar y borrar. Puesto que dentro de una aplicacin las estructuras de DDOs son generalmente estticas, normalmente slo se tiene que validar la estructura de grabacin y borrado una vez. Esto se efecta la primera vez que intenta grabar o borrar dentro de ese DDO. ste es el valor por defecto. Dinmicamente tendr que realizar esta validacin cada vez que quiera ejecutar una validacin o una grabacin. Aunque esto es poco habitual, est soportado para que lo pueda hacer en los casos en que los necesite. Tambin puede desactivar esta validacin, pero siempre con precaucin. Esto es un resumen de los modos de validacin: DD_VALIDATE_STRUCTURE_ALWAYS El Diccionario de Datos verificar las estructuras de tabla cada vez que un registro se grabe / se borre. Se desactiva la validacin estructuras de la tabla padre. de las
DD_VALIDATE_STRUCTURE_NEVER
DD_VALIDATE_STRUCTURE_ONCE
El error. El Diccionario de Datos verificar las estructuras de tabla la primera vez que se intente grabar despus de cargar la vista. Esto supone que la estructura no cambiar durante la sesin - normalmente una suposicin segura.
Pgina 65 de 92
Sistema y tablas externas

Send Add_System_File _Ordsys.File_Number DD_LOCK_ON_NEW_SAVE_DELETE Ciertas tablas deben conectarse a la estructura del servidor de datos para las cuales no hay razones para crear un objeto de Diccionario de Datos. Un ejemplo perfecto es una tabla de sistema que contiene un contador para propsitos de censo asignar claves de identificacin nicas. Esas tablas deben ser registradas en el Diccionario de Datos como tablas externas. Cuando escriba el cdigo en su Diccionario de Datos, que actualice una tabla no relacionada durante una transaccin (Ej. Cuando el DDO est bloqueando tablas y registros), esta tabla se debe aadir a la lista de tablas externas de la clase de Diccionario de Datos. Esto levantara los errores de cierre cuando su clave tratase de grabar una parada al archivo externo. Las tablas externas se declaran en las clases de Diccionario de Datos usando el mensaje Add_System_File. Si se usa una tabla externa, probablemente, se emplee dentro de uno o ms de los siguientes eventos: Update, Backout, Creating, Deleting, Validate_Save y Validate_Delete. Si hace referencia a una tabla externa en estos eventos, necesita aadir esta tabla a la lista de tablas externas. Si usa el comando Define_Auto_Increment para definir un campo de Auto-Incremento y la tabla que suministra automticamente ese Auto-Incremento es una tabla sistema, deber aadirla a la lista de tablas externas.
Send Add_System_File_ Ordsys.File_Number DD_LOCK_ON_NEW_SAVE_DELETE Define_Auto_Increment ordsys.last_cust_num to Customer.cust_number A menudo a las tablas de sistema no se les asigna un DDO sino que representan una excepcin de la regla que dice que una subclase de Diccionario de Datos debe crearse y usarse para cada tabla en una aplicacin. Puesto que las tablas de sistema contienen slo un registro que puede ser usado por muchos usuarios, hay un parmetro que optimiza y determina cundo debe bloquearse la tabla externa. Este parmetro tiene los siguientes valores:
DD_Lock_On_All
Se bloquea borrados.
en
todas
las
grabaciones
Pgina 66 de 92

DD_Lock_On_New_Save_Delete Se bloquea en las nuevas grabaciones y borrados. Se bloquea en todas las grabaciones. Se bloquea solamente en las grabaciones de nuevos registros. Se bloquea solamente en borrados.
DD_Lock_On_Save DD_Lock_On_New_Save
DD_Lock_On_Delete
Para tablas de sistema que soporten nmeros de serie de identificacin nicos, DD_Lock_On_New_Save debe ser suficiente; para tablas de contadores secundarios que incrementan y disminuyen, se necesitaran los otros dos modos por lo que DD_Lock_On_All sera apropiado. Note que esta optimizacin de bloqueo solamente se aplica a la Base de Datos embebida de DataFlex.
Pgina 67 de 92
Definir eventos Del Diccionario de Datos

Parte del proceso de creacin de Diccionario de Datos es definir los comportamientos personalizados de los eventos. Estos eventos permiten que personalice los procesos principales del Diccionario de Datos: Buscar (Find), Borrar (Clear), Guardar (Save) y Eliminar (Delete). Los eventos permiten que controle lo siguiente: Llevar a cabo las validaciones y la comprobacin de errores durante una grabacin o un borrado. Si se genera un error, se cancela la grabacin o borrado y se deshace cualquier cambio (Roll Back). Use los eventos para mantener balances entre tablas relacionadas durante las grabaciones y borrados. Use los eventos para definir y controlar las relaciones especiales entre tablas. Use los eventos para llevar a cabo procesos especiales cuando se encuentren nuevos registros. Esto incluye poner valores por defecto para los nuevos registros. Use eventos para llevar a cabo procesos especiales de grabacin o borrado.
Un evento puede ser usado por mltiples operaciones. Por ejemplo, el evento de Backout se convoca durante una grabacin y un borrado. El evento de Relate_Main_File puede ser convocado por las grabaciones, borrados, bsquedas y limpiar (Clear). Algunos eventos se convocan siempre en un estado de bloqueo (Ej. Update y Backout) mientras que los dems eventos pueden (o no) ser convocados en un estado de bloqueo (Ej. Relate_Main_File). Los eventos predefinidos del Diccionario de Datos son: Attach_Main_File Backout Clear_Main_File Creating Delete_Main_File Deleting Field_Defaults OnNewCurrentRecord Relate_Main_File Save_Main_File Update Validate_Delete
Pgina 68 de 92

Validate_Save
Forward sending mensajes de evento

Antes de nada una consideracin sobre lo que es Forward send. Traducido literalmente del ingls tendramos algo similar a enviar hacia adelante. Debe enviar siempre los mensajes de evento. Aunque algunos de los eventos de Diccionario de Datos no se activan por defecto, otros eventos llevan a cabo tareas muy importantes y deben ser Forward send. A menos que quiera cancelar un comportamiento especfico, es aconsejable que Forward send siempre sus eventos para aumentarlos (ampliar sus funcionalidades). Esto crea cdigo robusto que trabajar la primera vez y que continuar trabajando cuando se hagan cambios. As que mientras podramos codificar un evento de la siguiente manera: // Incorrect Procedure Update Move (Customer.due + order.total) to Customer.due End_Procedure En vez de esto lo codificaremos con un Forward send:
// correct Procedure Update Forward send Update Move (Customer.due + order.total) to Customer.due End_Procedure
Eventos de campo definidos por el usuario

Los Diccionarios de Datos permiten que defina eventos que deben ser llamados cuando un campo se valida o cuando se entra o sale de un formulario asociado a un campo determinado. Estos eventos se relacionan a campos que usan el Field_Validate_msg, Field_Entry_msg y Field_Exit_msg y se discuten en otros captulos. En particular, los eventos de validacin de campo pueden ser muy tiles.
Definir clases de Diccionario de Datos.
Pgina 69 de 92
Attach_Main_File
Attach_Main_File lleva a cabo un attach. Se llama durante operaciones de grabacin y borrado. Un Attach mueve los campos de datos relacionados de una tabla padre al DDO de una tabla hija. Esto asegura que los valores de relacin entre tablas se mantengan actualizados correctamente. Note que este Attach solamente se aplica a los DDOs padre que estn relacionados con este DDO. Si una tabla padre est relacionada con el de la tabla principal (Main Table) DDO pero no hay un padre DDO conectado al DDO, no ocurrir ningn Attach. Puede usar este procedimiento parea crear Attaches adicionales, cancelndolos todos o creando unos propios. La siguiente muestra efecta un Attach normal a no ser que uno de los Attach de campo se ignora.
Procedure Attach_Main_File String sTempVal Move Vndr.Parent_Stat to sTempVal / / remember this value // El Attach normal har un Attach de todas las Tablas padre // Incluyendo un Attach a Vndr.Parent_Stat. Queremos // ignorar este Attach Forward Send Attach_Main_File Move sTempVal to Vndr.Parent_State / / Deshaga este Attach End_Procedure Note que Attach_Main_File y Relate_Main_File no son verdaderos inversos entre ellos. Relate_Main_File no hace nada (la relacin sucede como parte del Find). Attach_Main_File lleva a cabo el comando Attach. Si no hace un Forward send del mensaje, el Attach no ocurrir. Cuando acceda a los valores de la tabla deber acceder a al Buffer global de la tabla y no al Buffer local del DDO (es decir, use la sintaxis de Move File.Field To Variable). Para ms informacin consulte Comprendiendo Buffer de ficheros y Buffers de DDOs.
Definir eventos de Diccionario de Datos.
Backout y Update
Los eventos de Update y Backout se usan para mantener balances de relacin entre tablas. Update es llamado en las modificaciones y altas de registros, mientras que Backout es llamado en las modificaciones y borrados de registros. Update y Backout se emplean generalmente para ajustar las tablas padre. Backout, concretamente, se emplea para eliminar el efecto de una grabacin mientras que la Update se usa para aadir el efecto de una grabacin.
Pgina 70 de 92

Los siguientes Update y Backout en un Diccionario de Datos ajustaran los totales de su padre, la tabla vndr.
Procedure Update Forward Send Update Move (Checks.Total.+ Vndr.Total_Paid) to Vndr.Total_Paid End_Procedure Procedure Backout Forward Send Backout Move (Checks.Total- Vndr.Total_Paid) to Vndr.Total_Paid End_Procedure Cuando se graba un registro Nuevo (Alta) se llama Update (y no a Backout). Cuando se borra un registro (Elimina) se llama a Backout (y no a Update). Cuando se modifica un registro existente se llama a ambos (Update y Backout). La mayora de las veces los contenidos de Update y Backout sern el inverso de s mismos. Si no lo son, deber revisar su lgica de forma cuidadosa. La mayora de las veces lo que Update aada a un total, Backout se encargar de restarlo. Es posible que Backout y Update puedan ajustar totales de diferentes tablas padre durante una edicin. Esto ocurrira si la edicin causase que el Registro padre cambie. Los DDOs soportan esto. No asuma que los eventos de Update y Backout solamente se envan una vez durante una grabacin. Si el Registro padre de un Registro hijo no se cambia, entonces Backout y Update se llaman una sola vez. En caso de que se cambie el Registro padre de un Registro hijo, entonces Backout y Update se llaman ms de una vez. Por ejemplo: supongamos que nuestra tabla de clientes est relacionada con una tabla de zonas geogrficas de forma que un cliente pertenece a una zona y una zona tiene mltiples clientes. En este caso, nuestra tabla hijo es la tabla de clientes y la tabla padre es la de zonas. Supongamos que en la tabla de zonas llevamos un total de ventas de cada zona que es la suma de las ventas de cada uno de los clientes de esa zona. Si a un cliente le cambiamos de zona (a un Registro hijo le cambiamos el padre) entonces Update y Backout se llaman ms de una vez. El proceso de mantener integridad relacional cuando se cambia el registro padre de un hijo es bastante complejo y ambos eventos pueden ser llamados mltiples veces para la misma tabla (para diferentes registros). Si un cambio en un registro debe ajustar totales en un Registro padre y abuelo (Ejemplo: el importe de una lnea ajusta los totales de la factura, y esta a su vez el crdito consumido del cliente), es mejor dejar que un Diccionario de Datos acte sobre su padre(s) inmediato(s) (lneas sobre factura y factura sobre cliente). Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones.
Pgina 71 de 92

Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Clear_Main_File
Clear_Main_File efecta un clear sobre la tabla principal del Diccionarios de Datos. Normalmente, querr realizar un Forward send de este mensaje y despus cualquier tipo de aumento. Si desea que este evento limpie (clear) una tabla adicional debe contar el Diccionario de Datos sobre esto enviando el mensaje Request_Clear_File:
Procedure Clear_Main_File Forward Send Clear_Main_File Clear AuxFile Send Request_Clear_File AuxFile.File_Number End_Procedure Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Creating (crear)
Creating es llamado como parte del proceso de grabacin y se llama cuando se va a grabar un nuevo registro. El comportamiento por defecto de este evento es para manejar Autoincrementos cuando este est definido en la clase con el comando Define_Auto_Increment. Por este motivo debe asegurarse reenviar el evento (Forward send) Este evento puede usarse para efectuar cualquier procesamiento adicional requerido para un nuevo registro.
Procedure Creating Forward send Creating Send LogNewRecordData End_Procedure
Pgina 72 de 92

Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones. Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Delete_Main_File
El evento de Delete_Main_File efecta el borrado (delete) del registro. Delete_Main_File est pensado para aumentarse Normalmente, querr siempre reenviar (Forward send) este mensaje. Si no se reenva no se borra el registro. Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones. Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Definir eventos de Diccionario de Datos
Deleting (borrar)
Deleting se llama durante el proceso de borrado (delete). Se enva antes del mensaje de Backout.
Procedure Deleting Forward send Deleting Send LogDeletedRecord End_Procedure Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento.
Pgina 73 de 92

Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones. Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Field_Defaults
El evento de Field_Defaults sirve para soportar los ajustes de los valores por defecto despus de un Clear. Puede fijar cualquier valor de campo, que se reflejar en los DEOs y ser guardado con el registro nuevo. Puesto que el ajuste de los valores por defecto se codifican en un procedimiento, se pueden crear reglas complicadas. El ajuste de un valor por defecto no es reconocido como un cambio de datos por el Diccionario de Datos; por lo tanto, el ajuste de los valores por defecto no generar un mensaje de aviso de "prdida de datos".
Procedure Field_Defaults Forward Send Field_Defaults Set Field_Changed_Value field Customer.State to FL Set Field_Changed_Value field Customer.Discount to (Discount(self)) Set Field_Changed_Value field Customer.City to "Miami" End_Procedure Los valores por defecto tambin pueden fijarse a la entrada de un DEO creando un mtodo Field Entry y ponindolo con la propiedad de Field_Entry_msg. Ese mtodo podra poner el valor por defecto usando el mensaje de Field_Default_Value.
On new current Record

On new current Record puede considerarse como un evento Post-Find/Clear/Save/Delete, puesto que se llama despus de cada Find, Clear, Save y Delete. Ocurre siempre que CurrentRowId cambie.
Pgina 74 de 92

A On new current Record se pasan dos parmetros de RowId: el RowId del registro viejo y el RowId del registro nuevo. Observando estos dos parmetros, puede decir si el DDO ha encontrado un registro o si est creando uno nuevo (si el nuevo RowId es nulo). No puede usar este procedimiento para cambiar el RowId en curso ya que este mensaje se enva para notificar un cambio que va a ocurrir. No puede abortar el cambio. On new current Record se enva cuando el registro en curso est cambiando, con dos excepciones: si se inicia un DDO y el registro que est establecido es nulo, se llamar On new current Record (el registro antiguo = nuevo registro nulo= nulo). Despus de una grabacin, se llama a On new current Record de todos los DDOs que participaron en la grabacin, incluso si el registro no cambi. Si lo necesita podr comprobar esta condicin con Operation_Mode y ver si es Mode_Saving.
Procedure OnNewCurrentRecord RowId riOldRec RowId riNewRec Forward Send OnNewCurrentRecord riOldRec riNewRec // Asumiendo que deseamos atrapar grabaciones de registros nuevos If (Operation_Mode = Mode_Saving AND ; IsSameRowId (riOldRec, riNewRec)) Begin : End Else.... End_Procedure
Notas especiales
Este mensaje debe ser reenviado (Forward Send). Este evento no existe en la versin 10.1 de Visual DataFlex. En vez de dicha versin se emplea el New_Current_Record. A este evento se le pasan los nmeros de registro (Integers) en lugar de RowIds. El evento de New_Current_Record todava se convoca pero se considera obsoleto. On new current Record es su sustituido preferido.
Relate_Main_File
Por defecto, Relate_Main_File no hace nada. Ocurre despus de que el Relate normal se haya ejecutado. Es un evento que permite ejecutar relaciones personalizadas despus de que su registro principal se haya encontrado y relacionado. Si va a encontrar registros nuevos en Relate_Main_File, debe notificar que el DDO ha encontrado este nuevo registro. Esto se hace enviando el mensaje de Request_Relate (si se encuentra el
Pgina 75 de 92

registro) o Request_Clear_File (si el registro no se encontr). Request_Relate tambin ejecutar un Relate el registro recin encontrado. Esto es particularmente verdadero si el DDO est actualizando el DDO padre del registro que ha encontrado. El siguiente cdigo que mostramos a continuacin encuentra un Registro padre y notifica al DDO que lo ha encontrado. (Nota: esta es lo que habitualmente se llama Sofi Find y no debe confundirse con Sofi Relate)
Procedure Relate_Main_File Boolean bMustFind Integer iFile iStatus Get Main_File to iFile Get_Attribute DF_FILE_STATUS of iFile to iStatus Forward Send Relate_Main_File If (iStatus = DF_FILE_INACTIVE) begin Move True to bMustFind end Else if (Vndr.Soft_id <>SoftFile.Soft_id) begin Move True to bMustFind end If bMustFind Begin / / Solamente relaciona SoftFile si es necesario Clear SoftFile Move Vndr.Soft_ID to SoftFile.Soft_Id Find eq.SoftFile.Soft_Id End Get_Attribute DF_FILE_STATUS of SoftFile.File_Number to iStatus If (iStatus<>DF_FILE_INACTIVE) begin Send Request_Relate SoftFile.File_Number End Else begin Send Request_Clear_File SoftFile.File_Number End End_Procedure Note la optimizacin de este procedimiento. La bsqueda en SoftFile se lleva a cabo slo si: el Buffer de SoftFile est vaco o si el registro en el Buffer no es el que queremos (los valores relacionados no son los mismos). Se recomienda optimizar sus bsquedas dentro de Relate_Main_File. Debido a que los DDOs no pueden saber qu est haciendo este procedimiento, no hay, tampoco, ninguna manera de optimizar estas bsquedas. En el momento en que un DDO piense que la relacin personalizada de un registro pudiese ser incorrecta, enviar Relate_Main_File. Esto sucede a menudo. Por eso es importante que optimice sus bsquedas (un proceso sencillo) para no ralentizar sus operaciones de base de datos. Preste atencin pues Relate_Main_File no siempre encuentra registros que se relacionan con el registro actual. Cuando se cambia el registro padre de un registro hijo, Relate_Main_File se llamar durante el proceso de grabacin para encontrar registros relacionados con el padre
Pgina 76 de 92

nuevo y el padre antiguo. Debido a esto, CurrentRowId (o el obsoleto Current_Record) no debe usarse en los procedimientos de Relate_Main_File. Dentro de Relate_Main_File debe de hacerse referencia al valor real del Buffer del fichero o el RowId (usar la funcin de GetRowId) de la tabla. Se puede usar OnNewCurrentRecord para hacer el seguimiento de cambios en CurrentRowId. Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Save_Main_File
Save_Main_File sirve para grabar el fichero principal. Puede usar Save_Main_File para tablas adicionales no relacionadas o para procesar cambios adicionales en su tabla. Save_Main_File se llama para cada tabla que se graba en una operacin del Diccionario de Datos. Este mtodo puede llamarse incluso si no hay ningn cambio para grabar. En tal caso, la grabacin fsica en la base de datos no ocurrir aunque se llame el evento. En este ejemplo, queremos grabar la fecha y hora en cada registro grabado. Puesto que fijar la fecha y la hora en un campo puede causar que un registro no modificado se grabe, nicamente cambiaremos dicho valor si se modifica el registro. Si se modifica el Buffer del fichero, marcaremos el registro con la fecha y hora.
Procedure Save_Main_File Boolean bChanged Interger iFile Get Main_File to iFile Get_Attribute DF_FILE_CHANGED of iFile to bChanged // Solamente marcamos el registro si este se ha modificado. Esto asume // que las funciones Crnt_Date y Crnt_Time ya existen. If (bChanged) Begin / / if record is changed at all Get Crnt_Date to Vndr.Date_Stamp Get Crnt_Time to Vndr.Time_Stamp End // now do the normal save behavior Forward Send Save_Main_File End_Procedure Normalmente, siempre haremos un Forward Send de este mensaje. Si el mensaje no se enva, la grabacin no tendr lugar. Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones.
Pgina 77 de 92

Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Update y Backout
Los eventos de Update y Backout se usan para mantener balances de relacin entre tablas. Update es llamado en las modificaciones y altas de registros, mientras que Backout es llamado en las modificaciones y borrados de registros. Update y Backout se emplean generalmente para ajustar las tablas padre. Backout, concretamente, se emplea para eliminar el efecto de una grabacin mientras que la Update se usa para aadir el efecto de una grabacin. Los siguientes Update y Backout en un Diccionario de Datos ajustaran los totales de su padre, la tabla vndr.
Procedure Update Forward Send Update Move (Checks.Total.+ Vndr.Total_Paid) to Vndr.Total_Paid End_Procedure Procedure Backout Forward Send Backout Move (Checks.Total- Vndr.Total_Paid) to Vndr.Total_Paid End_Procedure Cuando se graba un registro Nuevo (Alta) se llama Update (y no a Backout). Cuando se borra un registro (Elimina) se llama a Backout (y no a Update). Cuando se modifica un registro existente se llama a ambos (Update y Backout). La mayora de las veces los contenidos de Update y Backout sern el inverso de s mismos. Si no lo son, deber revisar su lgica de forma cuidadosa. La mayora de las veces lo que Update aada a un total, Backout se encargar de restarlo. Es posible que Backout y Update puedan ajustar totales de diferentes tablas padre durante una edicin. Esto ocurrira si la edicin causase que el Registro padre cambie. Los DDOs soportan esto. No asuma que los eventos de Update y Backout solamente se envan una vez durante una grabacin. Si el Registro padre de un Registro hijo no se cambia, entonces Backout y Update se llaman una sola vez. En caso de que se cambie el Registro padre de un Registro hijo, entonces Backout y Update se llaman ms de una vez. Por ejemplo: supongamos que nuestra tabla de clientes est relacionada con una tabla de zonas geogrficas de forma que un cliente pertenece a una zona y una zona tiene mltiples clientes. En este caso, nuestra tabla hijo es la tabla de clientes y la tabla padre es la de zonas. Supongamos que en la tabla de zonas Pgina 78 de 92

llevamos un total de ventas de cada zona que es la suma de las ventas de cada uno de los clientes de esa zona. Si a un cliente le cambiamos de zona (a un Registro hijo le cambiamos el padre) entonces Update y Backout se llaman ms de una vez. El proceso de mantener integridad relacional cuando se cambia el registro padre de un hijo es bastante complejo y ambos eventos pueden ser llamados mltiples veces para la misma tabla (para diferentes registros). Si un cambio en un registro debe ajustar totales en un Registro padre y abuelo (Ejemplo: el importe de una lnea ajusta los totales de la factura, y esta a su vez el crdito consumido del cliente), es mejor dejar que un Diccionario de Datos acte sobre su padre(s) inmediato(s) (lneas sobre factura y factura sobre cliente). Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones. Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Validate_delete
La funcin Validate_Delete se llama justo antes de que tenga lugar un borrado. Se bloquean todas las tablas que participan en el borrado. Si se genera un error o se devuelve un valor distinto de cero, se detiene el borrado. Una operacin de borrado eliminar el registro de la tabla principal y todos los registros relacionados de las tablas descendientes (hijos, nietos, etc). Esto se hace para evitar registros hurfanos. Esta comprobacin solamente ocurre si Cascade_Delete_State es verdadero y si hay una relacin padre- hijo entre tablas y la estructura de DDO es correcta. El Validate_Delete solamente se enva al DDO de la tabla principal sobre la que se quiere efectuar el borrado. Si se aprueba el Validate_Delete, el registro de la tabla principal y todos sus registros hijos sern eliminados. Si est prohibiendo supresiones en cascada, es esencial que enve (Forward Send) el mensaje Validate_Delete. La verificacin del borrado en cascada sucede como parte de este envo (Forward Send):
Function Validate_Delete returns Integer Integer iError Forward get Validate_Delete to iError If (not (iError)) Begin If (Customer.status = "A") Begin Error 306 Cannot delete active record End
Pgina 79 de 92

End Function_Return iError End_Function Todas las tablas de los DDOs participantes se bloquean durante Validate_Delete. Por lo tanto, la funcin debe ser rpida y no debe requerir nunca una introduccin de datos por parte del usuario. La excepcin de esto es el comando de Error. Un error generado durante el Validate_Delete ser diferido hasta que las operaciones de borrado hayan retrocedido (Roll Back) y las tablas hayan sido desbloqueadas. Un error en cualquiera de los eventos de borrado (Validate_Delete, Deleting, Backout, Delete_Main_File, etctera.) indica un retroceso de la transaccin (Transaction Roll Back). ste es un proceso especial. Cuando esto ocurra el cdigo pendiente de ejecutarse de la funcin no se procesar. Este mensaje se llama siempre en un estado de bloqueo. En este evento no pida ninguna introduccin de datos al usuario. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones. Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Validate_Save
Validate_Save se usa como la validacin final de un registro antes de grabarlo. Se enva a cada tabla en la estructura de DDO que participar en la grabacin. Ocurre cuando la base de datos est bloqueada y todos los valores de campo han sido actualizados. Puede consultar directamente el valor de cualquier buffer de fichero.campo y si cualquier valor o combinacin de valores son invlidos, puede detener la grabacin declarando un error o devolviendo un valor distinto de cero. Los datos en el buffer del fichero son exactamente los que van a ser grabados. La excepcin para esto es que los attach del buffer del fichero no han ocurrido todava. Esto quiere decir que un buffer de una tabla hijo podra no contener la informacin del padre para poner en el amortiguador de archivo durante el evento Attach_Main_File. El evento Attach_Main_File ocurre despus de Validate_Save. Todas las tablas de los DDOs participantes se bloquean durante Validate_Save. Por lo tanto, la funcin debe ser rpida y no debe requerir nunca una introduccin de datos por parte del usuario. La excepcin de esto es el comando de Error. Un error generado durante el Validate_Save ser diferido hasta que las operaciones de grabacin hayan retrocedido (Roll Back) y las tablas hayan sido desbloqueadas.
Pgina 80 de 92

Normalmente, un Validate_Save fallido generar un mensaje de error, como en el ejemplo de abajo.
Function Validate_Save returns Integer integer iError If (Invt.Qtv < 0) Begin Error DFERR_OPERATOR "Insufficient Inventory on hand' End Forward get Validate_Save to iError Function_Return iError End_Function Un error en cualquiera de los eventos de grabacin (Validate_Save, Update, Backout, Save_Main_File, etctera.) indica un retroceso de la transaccin (Transaction Roll Back). ste es un proceso especial. Cuando esto ocurra el cdigo pendiente de ejecutarse de la funcin no se procesar. Debido a que los buffers para todas las tablas que estn participando han sido actualizados, no deber buscar (find), limpiar (clear), borrar (delete) o modificar ningn buffer de fichero. Esto no debe de confundirse con la validacin de campo (Field Validation). La validacin de campo ocurre antes de que la base de datos se bloquee y antes de que los campos sean actualizados en el buffer del fichero. La validacin de campo puede usarse para manejar la mayora de las validaciones. Validate_Save se emplea, solamente, para manejar validaciones especiales que solamente puedan ser comprobadas en un estado de bloqueo y con datos actualizados. Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones. Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Pgina 81 de 92
Restricciones y (constraints y filtros)
filtros
Una restriccin (Constraint) es una limitacin sobre los registros de una tabla que van a ser visibles para un componente del programa (ej: una vista, un objeto de Web, un informe). Hay dos razones por las que podra querer limitar los registros en un DDO:
Cuando un DDO se relaciona con otro. Podra querer que el DDO hijo solamente mostrase los registros que se relacionan con el DDO padre. Esto se denomina restriccin relacionada con Relates-To Constraint. Una vista o un informe puede estar centrado en un subconjunto de registros. Podra especificar de qu clientes y de qu regiones se muestra la informacin. Esto se denomina Filtros por restriccin (Filter Constraints).
La restriccin a la hora de desarrollar el proceso. Herencia de las restricciones. Optimizacin de la bsqueda de las restricciones.
Pgina 82 de 92
Restriccin relacionada con Relates To Constraints

Set Constrain_File To Customer.File_Number Una relacin con restricciones solamente se emplea cuando se quieren mostrar los registros hijos relacionados con un DDO de una tabla padre. El ejemplo clsico de una restriccin relacionada lo podemos encontrar en el sistema Order Entry (ejemplo estndar de VDF) en donde en una rejilla se muestran los registros detalle (lneas de pedido) que pertenecen a un pedido (cabecera de pedido). Las restricciones relacionadas se definen usando la propiedad de Constrain_File en un DDO hijo. Esto se hace estticamente en el nivel de objeto de DD. El siguiente ejemplo restringira todos los registros de pedido a un registro de cliente:
Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is A OrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number End_Object / / oOrderHea_DD Los Diccionarios de Datos manejan las restricciones relacionadas de una manera muy especial. Cuando una restriccin relacionada est activa, las reglas de propagacin para Buscar (Find) y limpiar (Clear) son diferentes. Esto se comenta con detalle en Propagacin de DDO y restricciones relacionadas. Se deben cubrir varios requisitos para que las restricciones relacionadas funcionen de forma apropiada: Una relacin debe estar definida entre la tabla hijo y la tabla padre. Dicha relacin debe definirse dentro de Database Builder. Esto requiere que la tabla hijo defina el campo o los campos que se relacionan con su correspondiente conjunto de campos en la tabla padre. El valor del campo/campos con los que est relacionado en la tabla padre deben de ser nicos e identificar un registro. En definitiva, esos campos con los que est relacionado deben de formar un ndice por s mismos. La tabla hijo deber tener uno o ms ndices que permitan Bsquedas rpidas por los campos relacionados. Esto quiere decir que los primeros segmentos en esta tabla hijo deben contener los campos relacionados. El DDO hijo debe de estar apropiadamente conectado con el DDO padre, poniendo la propiedad de DDO_Server en el hijo.
Las reglas 1 y 2 son reglas estndar usadas para definir cualquier relacin padre-hijo de forma correcta. La regla 3 hace posible que los DDOs encuentren, rpidamente, registros relacionados.
Pgina 83 de 92

Permite que los DDOs salten a un ndice para encontrar el primer registro (o el ltimo) relacionado y saltando fuera del ndice cuando se encuentra el ltimo (o primero). Puede usar otros ndices no optimizados para encontrar los registros hijo relacionados, pero esto no es aconsejable con tablas con un gran volumen de datos pues las prestaciones no sern satisfactorias. En nuestro ejemplo anterior, esto requerira: La tabla Order contiene un campo (OrderHea.Customer_number) que encaja con un campo similar en Customer (Customer.Customer_Number). La relacin para la tabla Order se define en el Database Builder. La Tabla Customer contiene un ndice basado en Customer.Customer_Number. La tabla Order contiene al menos un ndice cuyo primer segmento es OrderHea.Customer_Number (OrderHea.Customer_Number x OrderHea.Order_Number). El Order DDO, oOrderHea_DD debe definir oCustomer_DD como un DDO padre y usar el mensaje set DDO_Server.
Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is A OrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number End_Object / / oOrderHea_DD Las restricciones relacionadas se puede aplicar en mltiples niveles. En el siguiente ejemplo, los pedidos (orders) son restringidas a clientes y los detalles del pedido (Order-Detail) restringidas al pedido. Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is A OrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number End_Object / / oOrderHea_DD Object oOrderDtl_DD Is A OrderDtl_DataDictionary Set DDO_Server To oOrderHea_DD Set Constrain_File To OrderHea.File_Number End_Object / / oOrderDtl_DD Estas clases de restricciones se usan habitualmente en informes y en entrada de datos tipo cabecera-detalle. Por ejemplo, encontrara primero un cliente luego un pedido (que es el hijo del cliente), posteriormente encuentra los detalle del pedido que son hijos del pedido.
Pgina 84 de 92

Los Diccionarios de Datos soportan Relleno automtico (Auto-Fill) que pueden ser usados conjuntamente con restricciones relacionadas. Una Bsqueda en un Diccionario de Datos padre relacionado siempre, notifica este cambio al Diccionario de datos hijo relacionado. Debido a que el DDO hijo debe contener un registro limitado vlido, si Auto_Fill_State es verdadero se podr encontrar el primer registro legtimo. Este comportamiento de relleno automtico (Auto-Fill) se usa de entrada de datos para rellener las parrillas de detalle (Detail Grids) Es una buena regla usar solamente las restricciones relacionadas estrictamente necesarias. Este tipo de restriccin (constraint) no es necesario ni para las grabaciones (saves) ni para los borrados (deletes). Solamente se utiliza para buscar registros
Restricciones y filtro.
Pgina 85 de 92
Restricciones de filtro
Las restricciones de filtro representan todas las restricciones no relacionadas y que sirven para filtrar los registros por cualquier conjunto de restricciones. Las restricciones de filtro se definen dentro de un DDOs en el mtodo OnConstrain y son especificadas dentro de este mtodo usando el comando de Constrain. Object oCustomer_DD Is A Customer_DataDictionary Procedure OnConstrain Constraint Customer.Status Eq "A" End_Procedure End_Object / / oCustomer_DD Las restricciones de filtro son aditivas. Si se definen mltiples restricciones dentro de un evento de OnConstrain, se deben cumplir todas las restricciones para encontrar un registro. Las restricciones de filtro tambin se aaden a restricciones relacionadas. En el siguiente ejemplo, solamente se encontrarn las rdenes si: se estn relacionado con el cliente en curso, i el tipo de orden es N, y si la empresa de transporte es FEDEX:
Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is A OrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number Procedure OnConstrain Constrain OrderHea.Shipper eq "FEDEX" Constrain OrderHea.Type eq N End_Procedure End_Object / / oOrderHea_DD Las restricciones del DDO padre las heredan sus DDOs hijos. Puede que este comportamiento por defecto no sea siempre deseado y puede ser desactivado configurando la propiedad de pbInheritConstraints a falso.
Tipos de restricciones de filtro

El mandato de Constrain soporta dos tipos principales de restricciones de filtro:
El archivo de filtro de campo (File.Field Filter)

El archivo de filtro de campo se emplea para especificar que el valor de un campo de una tabla debe tener un valor especfico. Tiene el formato general de:
Pgina 86 de 92
Constrain {filename.fieldname} {mode} {value} Algunos ejemplos de filtros de campo son:
Constrain OrderHea.Shipper eq "FEDEX" Get pbLowerDate to dLowerDate Constrain OrderHea.Date gt dLowerDate Get psStatusConstraint to sStat If (sStat<> "") Begin Constrain Customer.Status eq sStat End Los filtros de campo se crean y se evalan cuando se crea una restriccin y no cada vez que se encuentra un registro. Esto tiene ciertas ventajas. Debido a que el motor de restriccin sabe qu campo est siendo filtrado y qu tipo de evaluacin est siendo aplicada, es capaz de determinar si la restriccin, teniendo en cuenta el ndice usado para la bsqueda, puede ser optimizado. Si puede ser optimizado, la bsqueda del registro mucho ms rpida.
El filtro Constrain-As
El filtro Constrain-As se emplea para especificar que el registro se ajuste a unos criterios definidos por una expresin. Tiene el formato general de:
Constrain {filename} As ( expression) Algunos ejemplos del filtro Constrain-As son:
Constrain Customer As (Uppercase(Customer.Name) Contains "DATA") Constrain Customer As ( (Customer.Name Contains "DATA") Or ; ( (Customer.Type = "COMPUTER") And ; (Customer.Area_Code Matches "3?5") )) Constrain Customer As (TestValidity(Self)) La expresin debe devolver un valor de verdadero o falso. Si es verdadero, el registro es vlido y si no es filtrado. La restriccin de expresin (Expresion Constraint) es la ms flexible. Puede escribir cualquier expresin que desee, de cualquier nivel de complejidad. Generalmente, usar las expresiones de comparacin con And/Or. Tambin puede llamar a las funciones dentro de la expresin. Sin embargo, debido a su flexibilidad, esto es tambin el tipo de restriccin ms lento. La expresin se evala cada vez que se encuentra un registro. Adems, debido a que el motor de restriccin no tiene ni idea de qu est haciendo en realidad la expresin, una restriccin de expresin no puede
Pgina 87 de 92

ser optimizada (no puede saltar fuera de un ndice). Por lo tanto puede ser muy lento en tablas grandes. Si un archivo de filtro de campo puede hacer el mismo trabajo, es preferible que lo use. El filtro Constrain-As puede usarse conjuntamente con otros filtros. Si los otros filtros son capaces de optimizar una bsqueda, el motor de restriccin usar esas optimizaciones para llevar a cabo entrada y salida de ndice. Esto puede reducir el nmero de registros que tienen que ser evaluados usando el filtro Constrain-As y pueden dar un rendimiento satisfactorio.
Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is AOrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number Procedure OnConstrain Constrain OrderHea.Type eq N" Constrain OrderHea (OrderHea.Shipper= "FEDEX" or OrderHea.Shipper=UPS) End_Procedure End_Object / / oOrderHea_DD
Restricciones y filtros.
El proceso de creacin de las restricciones (Constraint)

Generalmente, un conjunto de Constraint se crea una vez y se usa muchas veces. Normalmente, el proceso de creacin ocurre automticamente cuando se activa una vista o un informe. Este proceso de creacin es automtico y por lo general no necesitar preocuparse por l. Podra tener restricciones que cambian dependiendo de la introduccin de datos u otras circunstancias. Por ejemplo, podra querer que algunos usuarios llenen la tabla de clientes con su pas y luego restrinjan el DDO a ese pas. Asegrese de que este cambio de restricciones se refleje en los DDOs. Esta reconstruccin se hace enviando el mensaje Rebuild_Constraints a todos los DDOs que lo requieran. El mtodo Rebuild_Constraints hace lo siguiente: Borra las Restriccin que estableci para el DDO que recibi el mensaje Enva OnConstrain al DDO que recibe el mensaje y aade todos los comandos Constrain al conjunto de Restricciones. Si se pone la propiedad de Constrain_File en el DDO, aade una Restriccin Relates-To al conjunto de Restricciones. Si los pbInheritConstraints del DDO son verdaderos, repite los pasos del 2 al 4 para todos los DDO padre.
Pgina 88 de 92

Generalmente, despus de cambiar una restriccin puede descubrir que su registro en curso no cumple con las Restricciones que acaba de aplicar. Debido a esto, necesitar encontrar un nuevo primer registro despus de reconstruir una restriccin. En el siguiente ejemplo, un DEO enva un mensaje a su DDO para pasar dos parmetros, el nuevo valor de restriccin y el ndice a utilizar para encontrar un nuevo primer registro:
Object Customer_DD is a Customer_DataDictionary Property String psStatusConstraint Procedure ConstraintByStatus string sStar integer iIndex Set psStatusConstraint to sStat Send Rebuild_Constraints Send Find FIRST_RECORD iIndex End_Procedure Procedure OnConstrain Sting sStat Get psStatusConstraint to sStat If (sStat<> "") Begin Constrain Customer.status eq sStat end End_Procedure End_Object
Herencia de las restricciones

Normalmente un DDO heredar las restricciones de su DDO padre. Una restriccin se forma o se reconstruye cuando el mensaje Rebuild_Constraints se enva a un DDO. Rebuild_Constraints crea una restriccin de expresin interna que contiene todas las reglas para filtrar el DDO. Bajo circunstancias normales Rebuild_Constraints hace lo siguiente: Limpia las restricciones en curso para el DDO. Enva el mensaje Constrain al DDO lo que dispara el evento OnConstrain. Ejecuta todos los comandos de Restriccin Constrain/Constraint dentro del evento de OnConstrain. Cada restriccin (constraint) se aade a la expresin de restriccin (constraint) interna del DDO. Despus de enviar OnConstrain, hay que verificar si la propiedad de Constrain_File es distinta de cero. Si esto es as se crea una restriccin relacionada (Relates-To Constraint). Este proceso (pasos del 2 al 4) se repite del DDO a la tabla para cada DDO padre y esto se repite para cada padre en la estructura de DDO.
Pgina 89 de 92

Una vez finalizado el DDO contiene una expresin de Restricciones que consiste en todas las restricciones (Constraint) definidas en el DDO principal y de todas las restricciones definidas en todos los DDOs padre. El DDO principal hereda todas las restricciones de todos sus padres, abuelos Cuando se encuentra un registro y se relacionan los padres, entonces se ejecuta la expresin de restriccin contra estos registros. Si falla cualquier restriccin, incluyendo las restricciones padre, el registro se considera no vlido. Por lo tanto, si se encuentra un registro principal y uno de sus registros padre contiene una restriccin no vlida, ese registro principal se considera no vlido. La mayor parte de las veces este mtodo funciona. Hay veces que la herencia de las restricciones puede interferir en el proceso. Considere una entrada de pedidos en el sistema. En el tpico sistema, su registro de detalle se relaciona con una cabecera de orden y una tabla padre de artculos. Asumiendo que quiere limitar los registros de existencias a artculos que estn activos (Ej. Constrain Invt.Status eq "A"), esto es perfectamente vlido para nuevos pedidos. Sin embargo, si carga un pedido antiguo que contiene artculos, esos artculos no saldran en su lista de lneas de pedido, lo que podra ser confuso. En tal caso, puede ordenar a los DDOs para que no hereden las restricciones configurando la propiedad de pbInheritConstraints. Cuando esto ocurra, todas sus lneas del pedido se mostrarn (porque la restriccin padre no se usa). Sin embargo, si tratara de seleccionar un nuevo registro de artculo, la restriccin de artculos se cumplira (porque la restriccin una bsqueda de artculos se ejecuta por el DDO de existencias.) Por ejemplo, considere que una estructura de DDO de pedido contiene una restriccin en el DDO de artculos que sirve para filtrar todos los registros bajo cierto precio. Cuando seleccione los registros de Invt filtrar solamente aquellos que puedan ser escogidos. En el DDO de detalle del pedido (Lneas de pedido), las restricciones no se heredan. Por lo tanto los pedidos se mostrarn correctamente con todos los registros de detalle incluso si el detalle apunta a un artculo (Invt) no vlido (se asume que era vlido cuando se cre el pedido).
Object oVendor_DD is a Vendor_DataDictionary End_Object // oVendor_DD Object oInvt_DD is a Invt_DataDictionary Set DDO_Server to oVendor_DD Procedure OnConstrain Constrain invt.Unit_price gt 100 End_Procedure End_Object // oInvt_DD Object oCustomer_DD is a Customer_DataDictionary End_Object // oCustomer_DD Object oSalesp_DD is a Salesp_DataDictionary End_Object // oSalesp_DD Object oOrderhea_DD is a Orderhea_DataDictionary Set DDO_Server to oCustomer_DD Set DDO_Server to oSalesp_DD End_Object // oOrderhea_DD Object oOrderdtl_DD is a Orderdtl_DataDictionary
Pgina 90 de 92

Set DDO_Server to oOrderhea_DD Set DDO_Server to oInvt_DD Set Constrain_File to Orderhea.File_Number // Constraints from parent (like Invt) will not be applied Set pbInheritConstraints to false End_Object // oOrderdtl_DD Set Main_DD to oOrderhea_DD Set Server to oOrderhea_DD
Poner restricciones padre en un DDO hijo

Si decide heredar las restricciones, tambin puede poner restricciones padre dentro de un DDO hijo. Deber usar el Filtro Constrain-As como filtro para hacerlo. Por ejemplo, su DDO de detalle del pedido podra contener lo siguiente:
Set pbInheritConstraints to False Procedure OnConstrain // La tabla del Constrain DEBE de ser el nombre del DDO de la tabla principal // pero la expresin puede referirse a un DDO padre Constrain OrderDtl AS (Invt.Active="A") End Algunos desarrolladores prefieren usar esta tcnica porque guarda todas las restricciones para un DDO en un nico sitio (Ej. No tiene que buscar en el DDO padre para filtros adicionales).
Restricciones y filtros
Optimizacin de bsquedas de restriccin

Si el DDO tuviera que recorrer toda la base de datos para cada bsqueda, los usuarios podran esperar mucho tiempo para localizar un registro o conjunto de registros. El DDO intentar optimizar la bsqueda usando el ndice que haya indicado y entrando directamente a esta parte del ndice. Siempre que se ejecute una bsqueda, las restricciones son evaluadas con el ndice en uso para ver si se puede hacer cualquier optimizacin. Este proceso es automtico y no tiene que programar nada. Sin embargo, si el ndice en curso no puede ayudar en la bsqueda, el DDO podra tener que recorrer toda la tabla. Si la tabla tiene muchos registros, esto podra ser lento. Debera comprobar siempre que las bsquedas estn optimizadas adecuadamente para el ndice que est usando (o por lo menos debera saber que las bsquedas no estn optimizadas). Las tcnicas para probar esto se comentan en Depurando DDOs.
Pgina 91 de 92

La propiedad de ordenacin
Set Ordering to 3 Cuando use restricciones y filtros, a menudo solamente ser ptimo un ndice. Cuando esto suceda, asegrese de que est usando ese ndice. Puede forzar el DDO para que use siempre un ndice concreto. Haga esto poniendo la propiedad de ordenacin del DDOs a este nmero de ndice. Normalmente, el valor de esta propiedad es - 1, lo que permite que use cualquier ndice solicitado por el mensaje de bsqueda.
Object oOrderHea_DD is an OrderHea_DataDictionary End_Object Object oOrderDtl_DD is an OrderDtl_DataDictionary Set DDO_Server to oOrderHea_DD Set Constrain_File to oOrderHea.File_Number Set Ordering to 1 // este es el nico ndece que puede ser optimizado End_Object
Pgina 92 de 92

Guía de Diccionario de Datos

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Guía de Diccionario de Datos

Diunggah oleh

Hak Cipta:

Format Tersedia

Soluciones abiertas para un mundo cambiante

Gua de Diccionarios de Datos

Soluciones abiertas para un mundo cambiante

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Introduccin a los Diccionarios de Datos

Usando Diccionarios de Datos mientras se desarrolla una aplicacin

Usando Diccionarios de Datos cuando se desarrolla una aplicacin

Gua de Diccionario de Datos

Trabajando con Diccionarios de Datos

Creando clases de Diccionario de Datos

Gua de Diccionario de Datos

Construyendo estructuras de Objeto de Diccionario de Datos

Gua de Diccionario de Datos

Usando objetos de Diccionario de Datos con las Aplicaciones de Windows

Gua de Diccionario de Datos

Usando Objetos de Diccionario de Datos con Aplicaciones Web

Gua de Diccionario de Datos

Diccionario de datos bsico y conceptos de tabla

Gua de Diccionario de Datos

Tablas, columnas y filas

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Identidad de disco y RowId

Find EQ Customer by 1 // find EQ by index 1

Gua de Diccionario de Datos

Tipo de datos de RowId

Gua de Diccionario de Datos

Funciones globales de RowId

FindByRowId GetRowId NullRowId IsNullRowId IsSameRowId SerializeRowId DeSerializeRowId

Gua de Diccionario de Datos

La interfaz de Diccionario de Datos de RowId

Send FindByRowId Send ReadByRowId Get CurrentRowId Get HasRecord

Gua de Diccionario de Datos

Gua de Diccionario de Datos

Transacciones, Bloqueos y soporte multi-usuario

Gua de Diccionario de Datos

Buffers de fichero y Buffers de campos de DDO

Gua de Diccionario de Datos

Comandos tipo File-Field y Field

Gua de Diccionario de Datos

Los comandos de tablas (File)

Gua de Diccionario de Datos

El API de base de datos

Gua de Diccionario de Datos

Definir clases de Diccionario de Datos

Gua de Diccionario de Datos

El constructor de Diccionario de Datos (Define_Fields)

Gua de Diccionario de Datos

Gua de Diccionario de Datos Consulte lo siguiente

Gua de Diccionario de Datos

Definir los atributos de tabla de diccionario de datos

Fijar su tabla principal (Main_File)

Campos clave (key Fields)

Gua de Diccionario de Datos

Gua de Diccionario de Datos Proteccin de grabacin y borrado

Gua de Diccionario de Datos