Guía de Diccionario de Datos

5/7/2018 Guía de Diccionario de Datos - slidepdf.com

http://slidepdf.com/reader/full/guia-de-diccionario-de-datos 1/92

Soluciones abiertas para un mundo cambiante

www.Moose-Software.com •••• www.VisualDataflex.es

Guía deDiccionarios de

Datos



Soluciones abiertas para un mundo cambiante

www.Moose-Software.com •••• www.VisualDataflex.es

Versiones documento

Versión Revisado por Páginas Fecha

1.0 Andrea Guimarães Versión inicial. Traducido de “Data

Dictionary Guide” de la ayuda de VDF 12.1

31/01/2008



Guía de Diccionario de Datos

www.VisualDataflex.es Página 3 de 92

Índice

Introducción a los Diccionarios de Datos ........................................................................ 9 Usando Diccionarios de Datos mientras se desarrolla una aplicación ...................................... 9 Usando Diccionarios de Datos cuando se desarrolla una aplicación ......................................... 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





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

Protección de grabación 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

Búsqueda automática (DD_AutoFind) ............................................................................ 38 Búsqueda automática GE (DD_AutoFind_GE) ................................................................. 39 UPPERCASE (DD_CapsLock) ......................................................................................... 39 Fuerza de escribir (DD_ForcePut) .................................................................................. 40 No-Enter (DD_NoEnter) ............................................................................................... 40





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 verificación (Checkbox) ................................................................................. 44 Rangos (Range).......................................................................................................... 44 Verificación (Check) .................................................................................................... 45 Tablas de validación (Validation Tables) ........................................................................ 45 Tabla de validación (Validation Table) ........................................................................... 46 Descripción de validación de tabla (Description Validation Table) ...................................... 46 Tabla de validación de archivo (File Validation Table) ...................................................... 47 Tablas de validaciones de código (Code Validation Table) ................................................ 47 Métodos de validación de campo (File Validation Methods) ............................................... 47 Errores de validación de campo (Field Validation Errors) .................................................. 48 Consulte lo siguiente ................................................................................................... 49

Aspecto del campo ......................................................................................................... 49 Máscaras (Masks) ....................................................................................................... 49 Etiquetas (Labels) ....................................................................................................... 49 Ayuda de estado (Status Help) ..................................................................................... 50 Controles de ventanas (Windows Controls) .................................................................... 50 Consulte lo siguiente ................................................................................................... 50





Métodos de entrada y salida ........................................................................................... 51 Método de entrada ...................................................................................................... 51 Método 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 foráneos en Diccionario de Datos ..................................... 56

Campos Foráneos clave .................................................................................................. 57 Consulte lo siguiente ................................................................................................... 58

Campos Foráneos indexados ........................................................................................... 58 Consulte lo siguiente ................................................................................................... 58

Campos Foráneos 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

Cómo trabaja la estructura de validación DDO ................................................................... 65 Modo de validación ..................................................................................................... 65 Consulte lo siguiente ................................................................................................... 66





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





Validate_delete ............................................................................................................. 79 Consulte lo siguiente ................................................................................................... 80

Validate_Save ............................................................................................................... 80 Consulte lo siguiente ................................................................................................... 81

Consulte lo siguiente ...................................................................................................... 82 Restricción 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 creación 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

Optimización de búsquedas de restricción ......................................................................... 91 La propiedad de ordenación ......................................................................................... 92 Consulte lo siguiente ................................................................................................... 92





Introducción a los Diccionarios deDatosEn Visual DataFlex, la implantación de las reglas de de negocio de su aplicación se expresan yadministran completamente por Diccionarios de Datos. Los Diccionarios de Datos crean una capaentre la lógica de aplicación y los datos. Esto aporta las siguientes ventajas:

• Permite a su aplicación interactuar más eficazmente con su base de datos. Los Diccionariosde Datos aumentan la información de su base de datos de forma independiente a los datosfísicos.

• Protege sus datos - los Diccionarios de Datos se aseguran de que solamente se añadan

datos válidos.• Centraliza la lógica de aplicación - toda la información y las reglas en un solo lugar. Si tiene

que hacer un cambio, hágalo solamente en un lugar y el resto se modificará solo.

Los Diccionarios de Datos se definen como clases. Creará una clase de Diccionario de Datos paracada tabla. Estas clases serán usadas mientras esté desarrollando su aplicación.

Usando Diccionarios de Datos mientras se desarrolla unaaplicación

Mientras esté desarrollando su aplicación, las herramientas de apoyo de Visual DataFlex usarán lainformación en sus clases de Diccionario de Datos para ayudarle en el proceso de desarrollo. Estainformación será usada cuando cree vistas de entrada en Windows, informes y páginas web.Studio y sus asistentes usarán el Diccionario de Datos para determinar:

• Qué tablas deben ser abiertas y cómo están conectadas.

• Qué tipos de controles deben ser usados para un campo especial (por ejemplo: el tipo delínea, casilla de verificación…)

• Qué etiquetas y contexto debe ser usado como ayuda para sus controles.

• Qué listas de consultas (lookup lists) deben ser usadas, cómo deben ser usadas y cuál serásu aspecto.

Los Diccionarios de Datos facilitan crear aplicaciones sólidas, con buena apariencia y fácilmentemantenible.

Usando Diccionarios de Datos cuando se desarrolla unaaplicación

Los Diccionarios de Datos se añaden a una aplicación creando Objetos de Diccionario de Datos(DDOs). A la hora de desarrollar una aplicación, los DDOs sirven para dos propósitos principales:

• Coordinan la actividad de la base de datos – en los objetos de entrada de datos- (DEOs).

• Proveen a un programa los servicios de validación y actualización de la base de datos.





Estos dos propósitos son distintos.

Creando una estructura de DDOs, conectando los objetos de manera apropiada y a la vez

conectando DEOs a esta estructura, garantizando la actividad de la base de datos de formacoordinada. 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 deDiccionario 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 lasbases de datos en estas clases. Esto se consigue creando propiedades, funciones yprocedimientos.

• Crear objetos (objetos de entrada de datos) en las vistas, objetos Web y otroscomponentes. Una estructura de DDO es un grupo de objetos de DD que se conectan paraproporcionar el acceso sincronizado a tablas relacionadas.

• Crear objetos (objetos de entrada de datos) ó métodos (funciones / procedimientos) dentrode las vistas, objeto Web u otro componente que se comunique con sus DDOs. Estopermitirá que vea, cree, edite o borre sus datos.

Creando clases de Diccionario de Datos

Creará una clase de Diccionario de Datos para cada tabla de su aplicación. Estas clases, basadasen la clase de DataDictionary, permiten que defina la información y se establezcan las reglas parauna tabla. Poniendo estas reglas en un único lugar (una clase) no tendrá que repetirlas en cadacomponente que acceda a la tabla. Las reglas que puede especificar en esta clase son:

• La estructura de la tabla.

• Cómo se puede conectar a otras tablas.

• Definir qué validaciones y propiedades se aplican a cada campo.

• Qué reglas deben ser aplicadas durante grabaciones (saves), borrados (deletes) yactualizaciones (updates).

• Otra información como los nombres de etiqueta o texto de ayuda.

Todos los cambios de datos pasan por los DDOs. Antes de que se cambien los datos losDiccionarios de Datos los validan para usar las reglas, simples o complejas, que usted hadesarrollado en sus clases de Diccionario de Datos.

Los Diccionarios de Datos son una clase tan importante que se ha desarrollado una herramientavisual, Database Builder, para crear y mantener esas clases. Pretendemos que utilice siempre estaherramienta para mantener sus Diccionarios de Datos. Database Builder crea el código fuentepara estas clases. En algunos casos este código se genera automáticamente seleccionando lasopciones apropiadas en el Database Builder mientras que en otros casos usted creará este códigousando el editor de código del Database Builder.





Para más información acerca del funcionamiento de esta herramienta vea: Definiendo clases deDiccionario de Datos.

Construyendo estructuras de Objeto de Diccionario de Datos

Un conjunto de tablas relacionadas son representadas en su aplicación como una estructura deobjeto (DDO) de Diccionario de Datos. Las estructuras de DDO son creadas dentro de variosobjetos contenedores diseñados para manejar DDOs. Algunos de los objetos contenedoresdiseñados para esto son:

• DbView: usados por aplicaciones de windows para la introducción de datos.

• ReportView: usados para pedir informes.

• BusinessProcess: éstos son utilizados por aplicaciones Windows y Web para manejar yprocesar por lotes.

• cWebBusinessProcess: usados en aplicaciones de Web que proveen todo el soporteposterior (Back end) para sus páginas HTML.

• cWebService: usados en aplicaciones de Web para suministrar el soporte para los serviciosWeb (Web services).

Las reglas para montar estructuras de DDO son las mismas para todos estos contenedores. Cadaobjeto de Diccionario de Datos debe ser creado y conectado a la estructura de forma apropiada.Esto es hecho a través DDOs hijo creando enlaces con los DDOs padre.

Cuando se monta apropiadamente, las estructuras de DDO proveen acceso sincronizado a una jerarquía de datos. Según sea necesario se propagan mensajes entre varios objetos DDentregando de esta forma un comportamiento homogéneo y consistente para las operaciones de

Buscar, Limpiar, Grabar y Borrar. Además se validan estas estructuras antes de permitir elcambiar datos.

El Studio maneja por usted la creación de estructuras de DDOs.

Para más información sobre estructuras de DDOs vea: Creando estructuras de Objeto deDiccionario de Datos (DDO).

Restricciones y filtros

Una tarea adicional de los DDOs es permitir que se puedan restringir y filtrar los registros dentrode un componente. Se soportan dos tipos de restricciones:

• Cuando un DDO se relaciona con otro, usted podría querer que el DDO hijo muestresolamente los registros que se relacionan con el registro en curso en el DDO padre. A estose llama Relates- To- Constraint o Restricción por Relación.

• Una vista o informe puede necesitar solamente de un subconjunto de datos de cada vez.Podría, por ejemplo, especificar clientes y filtrar por una determinada región o provincia. Aestos se les llama Filter Constraints o Restricción por filtro.

Ambas clases de restricciones (se pueden combinar juntas) se definen dentro de sus estructurasde DDO.

Para más información sobre restricciones y filtros vea: Restricciones y Filtros.





Usando los objetos de Diccionario de Datos

El objeto que contiene una estructura de DDO también contiene, a su vez, todos los objetos y

métodos necesarios para comunicarse con esos DDOs. Este proceso de comunicación está, por lotanto, totalmente encapsulado.

En algunos casos, esta comunicación ocurrirá entre un objeto de entrada de datos (DEO) y unDDO. Por ejemplo, una ventana contendrá DEOs que permiten que vea y edite sus datos. CadaDEO está asignado a un DDO y toda comunicación entre el DDO y el DEO es automática.

En otros casos, la comunicación ocurrirá entre un método (procedimiento o función) y un DDO.Por ejemplo, un objeto de proceso de datos (Business Process Object o BPO), un objetonavegador de web o un objeto de servicio de Web contendrán una estructura de DDO y losmétodos que usan el DDO.

En todos los casos, los DDOs son usados para el mismo propósito. Tienen que permitirle hacer lo

siguiente:• Buscar o borrar datos.

• Proporcionarle información sobre el valor de un campo del DDO.

• Producir cambios en un valor del campo de DDO.

• Validar y grabar datos.

• Validar y borrar datos.

En una aplicación de Web, la conexión entre su DDO y DEO (su navegador) es indirecta, oprocesada por lotes. Todos los cambios en un DDO son enviados al navegador en formato HTMLcomo un solo evento. Todos los cambios en un DEO (el navegador) son enviados al DDO una sola

petición de lote. Su Web Browser Object (WBO) coordina esta actividad.El mismo DDO es capaz de soportar diferentes interfaces (por ejemplo: controles de ventanas,páginas HTML, servicios Web) y por lo tanto, la habilidad del DDO de comunicarse con estasinterfaces variará. Sin embargo, la lógica básica de DDO y los servicios de validación estánsoportados en todas las plataformas. Por ejemplo, las validaciones de campo son siempreejecutadas antes de una grabación.

Puede encontrar más información en cómo usar DDOs en: Usando objetos de Diccionario de Datosen 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á integradacon los DDO. A estos objetos se les llama Data Entry Object (DEOs) u objetos de entrada dedatos. Cada DEO está unido a un campo en una tabla. Además, cada DEO especifica un DDO paraque actúe como su servidor.

Una vista constará de una estructura de DDO y un número de estos DEOs. Los mensajes,lanzados a menudo por la interacción de usuarios, son enviados del DEO a su servidor DDO. Losmensajes dicen al DDO que lleven a cabo una de las tareas de DDO que están en la lista de arriba(Buscar, Grabar, Borrar, etc…). Cuando el DDO haya terminado la operación solicitada, enviará losmensajes de notificación a todos los DEOs conectados. Los DEOs usarán estas notificaciones paraactualizar sus datos y su apariencia. La sincronización entre DEOs y DDOs permite que estos





objetos de entrada sean completamente Data Aware (Consciente de Datos). Añadiendo muy pococódigo, podrá crear sofisticadas aplicaciones de entrada de datos.

Las Aplicaciones Windows también pueden usar DDOs dentro de informes. Un informe definirá unDDO para actuar como su servidor. Todas las búsquedas serán manejadas automáticamente pormensajes 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 debecontener métodos personalizados que ejecuten los procesos. Cree su código en estos métodospara controlar la actividad entre el DDO y el proceso. Existe una interfaz completa de Diccionariode Datos que le permite escribir un código que ejecute los mismos tipos de tareas que las quehacen automáticamente los DEOS (por ejemplo: limpiar, buscar, modificar datos, grabar,borrar…).

Usando Objetos de Diccionario de Datos con Aplicaciones Web

Las aplicaciones Web usan objetos Web para manejar todos los procesos. Hay dos tipos de objetosWeb:

• Objetos de navegador web o Web Browser Object (cWebBusinessProcess) – Seemplean para interactuar con el navegador de web basado en páginas.

• Objetos de Servicios Web o Web Service Objects (cWebService) – Se emplea paraproveer servicios de web.

Estos objetos están diseñados para contener las estructuras de DDO y los métodos que secomunican con esos DDOs. Un desarrollador interactúa con los DDOs de la misma forma con laque operan con un BPO en una aplicación windows.

Los WBO esperan que la interfaz visual sea provista creando páginas HTML. Esas páginas soncreadas (programadas) usando un servidor de páginas activas (ASP). Las páginas ASP hacen lasllamadas en los WBO. Dentro del WBO cree los métodos para hacer lo que sea necesario. Acontinuación haga sus métodos disponibles a su página ASP publicando su Interfaz. Además, losWBO contienen una serie de interfaces que dan acceso a sus Diccionarios de Datos. Esto permiteque lleve a cabo todas las funciones básicas del Diccionario de Datos (por ejemplo: buscar,borrar, grabar, limpiar,…) sin tener que escribir código en los WBO.

Los WBO proveen soporte de servicio web. Un servicio web puede o no necesitar acceder alDiccionario de Datos. Si lo hacen, se puede añadir una estructura de DDO al servicio de objetoweb o Web Service Object (WSO) y crear métodos que se comuniquen con los DDOs.





Diccionario de datos básico yconceptos de tabla

1. Tablas, columnas y filas2. Í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





Tablas, columnas y filas

Generalmente las bases de datos se definen como una colección de tablas. Las tablas constan deun juego de columnas designadas con un tipo de datos específicos y con una longituddeterminada. Los datos en las tablas se denominan filas.

Los mensajes de interfaz de Diccionarios de Datos usan la siguiente terminología para describirlas bases de datos:

• FILE- un “file” (archivo) hace referencia a una tabla.

• FIELD- un “Field” (campo) hace referencia a un campo.

• RECORD- un “Record” hace referencia a una fila de datos de una tabla.

Los mensajes del Diccionario de Datos usan ficheros (files), campos (field) y registros (records)en sus nombres de interfaz. Algunos ejemplos de esto son “Main_File”, “Field_Options”,

“File_Field_Current_Value”, y “OnNewCurrentRecord”.

Mientras que la documentación usará algunos de estos términos indistintamente, el uso normal deestos será:

• La tabla se usa cuando se consultan tablas de la base de datos. Solamente deberá ver lapalabra “file" en los mensajes de interfaz.

• El campo se usa cuando se consultan las columnas de una tabla y cuando se hacereferencia a la entidad en el Diccionario de Datos que define una columna. Un Diccionariode Datos mantiene las estructuras de la información sobre la columna como valores,

etiquetas, y opciones (“Field_Current_Value”, “Field_Label”, “Field_Options”) de cada tabla.Éstos serán referencias como campos (fields) dentro del Diccionario de Datos.

• Los registros (records) se usan para hacer referencia a una fila de datos de una tabla.

Consulte lo siguiente

Diccionario de datos básico y conceptos de tabla





Índices

En el Diccionario de Datos todas las búsquedas de información se producen usando índices. Losíndices se utilizan para encontrar rápidamente registros individuales y para buscar en una tabla(hacia delante o hacia atrás) en un orden específico.

Para ser usadas adecuadamente por los Diccionarios de Datos, cada anotación en los índices debeser única. En otras palabras, los segmentos usados para crear un índice no deben admitirduplicados (deben poder identificar un registro). Generalmente la singularidad está asegurada sise añade el campo de clave primaria como el último segmento(s) del índice.

Los índices se definen dentro del Database Builder con un número de índice. Ese número se usaen los Diccionarios de Datos y en el código de sus programas para determinar qué índice deberíausarse.







Relaciones

Las relaciones sirven para "normalizar" sus datos. Algunos de los objetivos de la normalizaciónson:

1. La eliminación de grupos repetitivos - Haga una tabla de consulta (lookup list) distintapara cada juego de atributos relacionados, y de una clave primaria a cada tabla. Porejemplo, podría estar grabando contactos en sus clientes. No deberá guardar los contactosen la tabla de clientes; sin embargo pondrá la información de contacto en una tabladistinta 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 unaclave multisegmento, retírelo a una tabla distinta. Supongamos que cada contacto quetenga con un cliente es categorizado (llamada telefónica, correo, visita personal, etcétera).Deberá guardar el tipo de contacto en una tabla distinta y relacionar los contactos con lostipos de contactos.

3. Eliminar columnas que no sean dependientes de una clave- Si los atributos nocontribuyen a una descripción de la clave, retírelos a una tabla distinta. Por ejemplo,suponga que está almacenando el nombre del cliente, dirección de “Empresa” y número deteléfono de “Empresa”. Estos atributos describen el lugar del trabajo del cliente, no elcliente, así que deberá crear una tabla de “Empresa” y quitar la información de “Empresa” de la tabla del cliente pasándola a esta nueva tabla relacionando la tabla de clientes conesta otra.

Éstas son las primeras tres formas de la normalización de datos y son probablemente las tres quemás desee aplicar comúnmente en su base de datos.

Las relaciones se representan en Visual DataFlex usando el modelo de clave foránea (foreing key)y clave primaria (primary key):

1. Una relación debe ser definida de “tabla hijo” a “tabla padre”. Una “tabla hijo” define a uncampo o conjunto de campos que se corresponden con un conjunto de datos en el “padre”.El tamaño y el tipo de datos de campo en el padre y el hijo deben ser los mismos. Estarelación se define usando el Database Builder.

2. Los valores de los campos relacionados en el padre (Ej. A, B y C) deben ser únicos ysoportados por un índice cuyos segmentos son los mismos que los campos relacionados (A,B, C de arriba). El campo relacionado en la “tabla padre” es casi siempre su clave primaria

y se refiere en el Diccionario de Datos como el campo clave (key field).

3. La “tabla hijo” generalmente tiene uno o más índices que permiten la búsqueda rápida porlos campos relacionados. Esto quiere decir que los primeros segmentos en este hijo debeconsistir de los campos a los que se relacionan.

Los Diccionarios de Datos utilizan las relaciones en cuatro maneras:

1. Relacionar: cuando un Diccionario de Datos encuentra un registro, todos los DDOs “padre” encontrarán automáticamente todos los registros relacionados. El DDO “padre” deesos DDOs buscará y encontrará los registros relacionados en la estructura superior (lo quese dice normalmente “hacia arriba”). De esta forma el buscar/relacionar encuentra unaestructura entera de registros relacionados.





2. Agregados: antes de una grabación (save) o búsqueda (find) los valores de los camposrelacionados al “padre” se mueven a los campos relacionados de los “hijos”. Este procesode agregar (attach), asegura que la “tabla hijo” y la “tabla padre” se relacionen de forma

apropiada durante las grabaciones.3. Restricciones (filtros): una restricción (constrain) de una relación definida en la

estructura de un Diccionario de Datos restringe la búsqueda de registros “hijo” a losrelacionados al “padre” . Esta característica es usada exhaustivamente en aplicaciones tipocabecera-detalle (por ejemplo en un sistema de introducción de pedidos en donde losdetalles-líneas de pedido deben estar restringidos a un pedido).

4. Validaciones y grabaciones: una validación ocurre antes de que suceda una validaciónde grabación en el DDO Principal y en todos los DDOs “padre” relacionados. Además, laestructura de DDO es inspeccionada antes de la grabación. Si la estructura entera no estáen su lugar, la validación fallará. Cuando ocurre una grabación (save), el registro en elDDO Principal y todos los registros de los DDOs “padre” son grabados como una única

transacción.Básicamente, las relaciones en Diccionarios de Datos permiten que trabaje con una jerarquía deregistros como una sola entidad.







Identidad de disco y RowId

Cada tabla necesita un identificador único que identifique cada registro. Este identificador seencarga de encontrar los registros y deberá hacerlo de la forma más rápida posible

Algunas bases de datos tienen un identificador de registro incorporado en cada tabla. La base dedatos de DataFlex y la de Pervasive.SQL atribuyen identificadores numéricos únicos a cadaregistro. Estos identificadores, referenciados como Recnum, establecen la manera más rápidaposible de encontrar un registro.

La mayoría de las bases de datos de SQL como SQL Server de Microsoft y DB2 de IBM noincorporan una identificación de registro. En vez de esto, las tablas en estas bases de datoscontienen claves primarias y un índice que provee acceso rápido a cualquier registro a través deesta clave primaria. La clave primaria puede ser definida como una sola columna o unacombinación de columnas. El tipo de datos de la columna(s) que forma(n) la clave primariapuede(n) ser de cualquier tipo(s).

Si su base de datos soporta Recnum, puede usar comandos basados en Recnum y mensajes deDiccionario de Datos para identificar y buscar registros.

// Low level commands using recnumInteger iTempRecMove Customer.Recnum to iTempRecClear Customer

:Move iTempRecnum to Customer.RecnumFind EQ Customer by recnum

// Data Dictionary methods using recnumInteger iTempRecInteger iFileGet Current_Record of hoDDO to iTempRecSend Clear to hoDDO:Get Main_File of hoDDO to iFileSend Find_by_Recnum of hoDDO iFile iTempRec

Si su base de datos usa una clave primaria como único identificador, podrá usar otros comandos ymensajes de Diccionario de Datos para identificar y buscar registros.

// low level commands using primary keyString sTempIdMove Customer.Customer_Id to sTempIdClear Customer:Move sTempId to Customer.Customer_Id

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





// Data Dictionary methods using primary key

String sTempIdGet Field_Current_Value of hoDDO Field Customer.Customer_Id to sTempIdSend Clear to hoDDO:Move sTempId to Customer.Customer_IdSend Find of hoDDO EQ 1 // find EQ mode and index 1

El ejemplo anterior supone que la clave primaria de la tabla de clientes es “Customer.Customer_Id” y su índice es el 1. Cada tabla tendrá una definición diferente para suclave primaria e índice de clave primaria. Dependiendo de su tabla necesitará modificar el códigoanterior para soportar una clave primaria diferente, diferentes nombres de campos, diferenteíndice de clave primaria y diferentes tipos de datos de clave primaria

Hay una desventaja muy importante con los métodos anteriores. Se requiere una sintaxisdiferente para bases de datos diferentes y para algunos casos también se requiere una sintaxisdistinta para cada tabla. Esto quiere decir que es muy difícil escribir un código que pueda serabstracto aplicado a cualquier tabla de cualquier base de datos. Este tipo de abstracción es unobjetivo y requisito de la programación de Diccionario de Datos.

Esto se resuelve introduciendo RowIds.

El identificador de registro de cada tabla se correlaciona con un tipo especial de datos llamadoRowId. Se define la correlación del identificador de registro al RowId al definir la tabla enDatabase Builder. Una vez correlacionado, un conjunto de comandos de RowId, funciones ymétodos del Diccionario de Datos se usan para buscar e identificar registros. Esto permite usar lamisma sintaxis con cualquier tabla.

// Low level commands using RowIdRowId riTempIdBoolean bFoundMove (GetRowId(Customer.File_Number)) to riTempIdClear Customer:Move (FindByRowId(Customer.File_Number,riTempId)) to bFound

// Data Dictionary methods using RowIdRowId riTempIdGet 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 decualquier base de datos. Una vez definido, simplemente programe usando RowId.

Tipo de datos de RowId





RowId riTempId1 riTempId2:Property RowId priLastId

:Get priLastId to riTempId1Move roTempId1 to riTempId2Set priLastId to riTempId2

RowId es un tipo especial de datos que sirve para almacenar valores RowId. Este tipo de datostiene un comportamiento. Puesto que el tipo de datos subyacentes puede ser de cualquier tipoo de cualquier combinación de tipos, no puede ser asociado a ningún otro tipo de datos ousado directamente para realizar cualquier tipo de evaluación. En vez de eso se entregan unconjunto de funciones globales de RowId y de métodos de Diccionario de Datos que permitenmanipular RowId.

Funciones globales de RowId

Las siguientes funciones dan soporte de bajo nivel a RowId:

FindByRowId Move (FindByRowId(iFile,riRowId)) to bFound

GetRowId Move (GetRowId(iFile)) to riRowId

NullRowId Move (NullRowId()) to riRowId

IsNullRowId

Move (IsNullRowId(riRowId)) to bIsNull

IsSameRowId Move (IsSameRowId(riRowId1,riRowId2)) to bIsSame

SerializeRowId Move (SerializeRowId(riRowId)) to sSerializedRowId

DeSerializeRowId Move (DeSerializeRowId(sSerializedRowId)) to riRowId

Estas funciones permiten que lleve a cabo cualquier evaluación de RowId que se necesite en unnivel bajo:

Function RunOrderDtlReport RowId riHdrId Returns RowIdRowId riEndBoolean bFoundMove (FindByRowId(OrderHea.File_Number,riHdrId)to bFoundIf bFound Begin

Set priStartRowId To (NullRowId())Get DoRunReport To iStatGet priEndRowId To riEnd

EndElse Begin

Move (NullRowId()) To riEndendFunction_Return riEnd

End_Function





La interfaz de Diccionario de Datos de RowId Los Diccionarios de Datos también proveen una interfaz completa para trabajar con RowId:

Send FindByRowId Send FindByRowId of hoDDO iFile riRowId

Send ReadByRowId Send ReadByRowId of hoDDO iFile riRowId

Get CurrentRowId Get CurrentRowId of hoDDO to riRowId

Get HasRecord Get HasRecord of hoDDO to riRowId

Estos métodos, junto con las funciones globales de RowId se pueden usar para manejarcualquier tipo de programación de RowId usando Diccionario de Datos.

Function RunOrderDtlReport RowId riHdrId Returns RowIdRowId riEndBoolean bFoundInteger iMainGet Main_File of oOrderHea_DD to iMainSend FindByRowId of oOrderHea_DD iMain riHdrIdGet HasRecord of oOrderHea_DD to bFoundIf bFound Begin

S

et priStartRowId To (NullRowId())Get DoRunReport To iStatGet CurrentRowId of oOrderDtl_DD To riEnd

EndElse Begin

Move (NullRowId()) To riEndendFunction_Return riEnd

End_Function

Notas especiales • No confunda RowId con clave primaria. Si su base de datos soporta campos de recnum, sus

tablas probablemente todavía tendrán una clave primaria (Ej. tendrán un campo o conjuntode campos que están indexados de forma única) que será identificado en su clase deDiccionario de Datos activando la propiedad “Key_Field_State”. Ese es el campo que usaráen las relaciones. Mientras esos campos, en teoría, podrían usarse para identificar RowId,no lo harán porque la definición interna de Recnum de la base de datos provee la maneramás rápida de encontrar un registro. Le interesa siempre usar el método más rápido paraencontrar los registros. Deberá usar siempre aquel método que su base de datos ocontrolador provea que es más rápido.





• RowId fue añadido en la versión 11.0 de Visual DataFlex. Antes de esta versión, todas lastablas tenían que soportar un Recnum (ej. todas las tablas tenían que soportar un camponumérico y único). La introducción de Rowid levanta esta restricción. La programación al

estilo de Recnum todavía se soporta. Si un desarrollador sabe que todas sus tablascontendrán un Recnum, pueden continuar programando usando comandos y métodos deRecnum.


Diccionario de Datos básico y conceptos de tablas





Transacciones, Bloqueos y soportemulti-usuarioLas transacciones y el soporte de bloqueo de base de datos están embebidos directamente en elDiccionarios de Datos. Las actualizaciones de base de datos (grabaciones y borrados) sonsiempre, por lo tanto, seguros a nivel multi-usuario. Administrar las transacciones es un procesoautomático que no requiere ningún esfuerzo adicional de programación por parte deldesarrollador.

Retroceso (Rollback) en las transacciones está también embebido en el Diccionario de Datos. Sipor cualquier razón una transacción de grabación o borrado no puede ser terminada, se deshace

la transacción entera y no se realiza ningún cambio en la base de datos.

Se bloquea la base de datos durante una transacción. Las tablas que participan en la transacciónestarán bloqueadas para escritura (write lock). Esto permite que otros usuarios lean datos de lastablas pero no que ellos escriban datos hasta que los bloqueos sean liberados. Los bloqueos seliberan cuando una transacción ha finalizado como una grabación exitosa (successfull commit) ocon un retroceso fallido (failed rollback). Dependiendo de la Base de Datos los bloqueos se aplicana nivel de registro o a nivel de tabla.

Los procesos de Transacciones y Bloqueos se comentan con más detalle en Transacciones yDDOs.


Diccionario de Datos Básico y Conceptos de Tabla





Buffers de fichero y Buffers decampos de DDOCuando se abre una tabla en una base datos, se crea una memoria intermedia (buffer) de ficheroconteniendo los valores de los campos para un registro. La búsqueda (find) y limpieza (clear) deregistros mueven datos de la tabla (.DAT) a este Buffer. Las grabaciones (save) mueven los datosdel Buffer a la tabla. Se definen variables globales, llamadas “File.Filed” que dan acceso alprograma a esos Buffers, permitiendo que los programadores accedan y cambien los datos delregistro actual.

// Move from file buffer to a variableMove Customer.Name to sName

// Move from variable to the file bufferMove sName to Customer.Name

Los DDOs (Data Dictionary Objects) mantienen actualizados los Buffers locales, que mantienen lainformación sobre el registro en curso del DDO. A estos se les llama Buffers de campo DDO (DDO-Field Buffer). Estos Buffers locales permiten a las aplicaciones soportar DDOs múltiples que usanla misma tabla.

// Move from DDO-Field buffer to a variableGet Field_Current_Value of hoDDO Field Customer.Name to sName

// Move from variable to the DDO-Field bufferSet Field_Changed_Value of hoDDO Field Customer.Name to sName

Hay veces que quiere interactuar con los Buffers globales del archivo (.DAT) directamente y otrasque quiere interactuar con los Buffers de campo DDO. Esto se comenta con detalle enEntendiendo Buffers de fichero y Buffers de campos de DDO.

Consulte lo siguienteDiccionario de Datos básico y conceptos de tablas





Comandos tipo File-Field y Field

La información del campo de Diccionario de Datos se almacena y se puede acceder a ella a travésde una interfaz de campo. Esta interfaz requiere que pase como parámetros un identificador decampo y a veces un identificador de tabla. Estos parámetros deben ser pasados como valoresenteros (Integers). Las palabras clave especiales, “Field” y “File_Field”, permiten que pase estosparámetros como nombres en lugar de números. El compilador cambiará estos por las constantesde números apropiadas. Algunos ejemplos de uso de estas palabras clave son:

// use of the field keywordGet Field_Current_Value of oCustomer_DD Field Customer.Name to sNameSet Field_Changed_Value of oCustomer_DD Field Customer.Name to sName

// use of the File_Field keywordGet File_Field_Current_Value of oOrder_DD File_Field SalesP.Name to sNameSet 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 objetode 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 estoscuando el objeto de Diccionario de Datos que recibe el mensaje quizás 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_Fieldse 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 loscomandos de tipo File_Field y Field.


Diccionario de Datos básico y conceptos de tablas





Los comandos de tablas (File)

El lenguaje de DataFlex soporta varios comandos que permiten que acceda a tablas directamentefuera de los Diccionarios de Datos. Esos comandos son:

• Buscar

• Borrar

• Guardar a Disco

• Borrar

• Cerrar

• Relaciónese

• Attach

Normalmente, cuando use Diccionarios de Datos no necesitará usar estos mandatos. En algunosde los eventos de Diccionario de Datos puede usarlos para manejar las operacionespersonalizadas de bajo nivel. Por ejemplo, podría desear llevar a cabo alguno tipo de búsquedapersonalizada en el proceso de “Relate_Main_File”. En estos casos podría usar estos comandos.

Además, podría usar estos comandos y limitar el uso de un Diccionario de Datos. Es más probablehacer esto cuando se busquen registros. Usar un comando directo para grabar o borrar registrosno es recomendable porque estaría evitando todas las reglas de validación que los DDOs hacencumplir.







El API de base de datos

El lenguaje de DataFlex tiene un juego de comandos que permite consultar cualquier informaciónsobre sus tablas. Estos son referidos como los atributos del Api de la base de datos. El comandode Get Attribute se emplea para consultar el valor de cualquier atributo de API. Puede usarlospara consultar información sobre:

• Una tabla (nombre, descripción, número de campos, número de índices, número deregistros).

• 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 mejorque acceda a esta información directamente dentro de un DDO o de un componente usando elcomando de Get_Attribute. La mayoría de estos atributos son de bajo nivel por lo que rara veznecesitará acceder a ellos. Si no puede encontrar un mensaje de DDO que devuelva lainformación que necesita, verifique los atributos de API. Dentro de una aplicación, lo mássolicitado, aparte de los atributos de API, son la longitud de campo y el tipo de datos del campo.

El comando Set_Attribute también puede usarse para cambiar atributos de la base de datos. Raravez necesitaría hacer esto dentro de una aplicación.

Consulte lo Siguiente






Definir clases de Diccionario deDatos

Antes de que pueda usar Diccionarios de Datos debe crear una clase para cada tabla en suaplicación. Database Builder se encargará de hacer esto. Aunque Database Builder es unaherramienta de diseño visual, el resultado final de esta herramienta es el código fuente. LosDiccionarios de Datos son simplemente un código fuente basado en clases que se complican en suaplicación.

El propósito de esta sección es describir las características de una clase de Diccionario de Datos yexponer la interfaz de Diccionario de Datos (ejemplo: exponer el código fuente). Esperamos queuse Database Builder para mantener siempre actualizado sus Diccionarios. Parte del código dentrode las clases de Diccionario de Datos es creado y mantenido por el interfaz visual de DatabaseBuilder. Otras partes de la clase, en particular los eventos, requerirán que usted cree un códigopersonalizado.

Algunas de las propiedades y eventos descritos en esta sección también pueden ser definidas enel nivel de objeto de Diccionario de Datos. Cuando trabaje en el nivel de objeto necesitará sabercómo 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 Diccionariode Datos. Esto incluye los atributos de tabla, los atributos de campo, los atributos decampo externos (foreing field) y las relaciones de tablas “padre/hijo”. Todos estos atributosse mantienen fijando propiedades dentro de un procedimiento llamado “Define Fields”.

• Eventos de Diccionario de Datos: se llaman varios eventos durante las operaciones del DataDictionary: la búsqueda, grabar, eliminar y borrar. Estos eventos pueden ser creados para

tratar los requisitos personalizados para una tabla. Estos requisitos incluyen fijar los valorespor defecto, llevar a cabo las validaciones y controlar las relaciones entre tablas. Además,el desarrollador puede proporcionar los eventos personalizados y asignarlos a campos.Estos eventos son lanzados por las operaciones específicas como la validación de campo ynavegación. Todos estos eventos son creados como funciones y procedimientos que eldesarrollador debe crear.





El constructor de Diccionario deDatos (Define_Fields)El método de construcción especial, “Define_Fields”, se emplea para definir todos los atributos delDiccionario de Datos. Este método de construcción define los siguientes tipos de información:

• Atributos de tabla: definen los atributos que son aplicables a la tabla entera. Esto conectasu Diccionario de Datos a una tabla específica y define las capacidades básicas delDiccionario de Datos.

• Atributos de campo: definen atributos para cada columna en su tabla. Esto provee reglas devalidación de campo, reglas de búsqueda y mucha información 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 relación entre tablas. Esto sirve paraayudar a construir estructuras DDO y verificar que estas estructuras sean capaces desoportar apropiadamente las actualizaciones de base de datos.

Todos estos ajustes se crean y se mantienen actualizados usando Database Builder. El listado deabajo 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_FINDREQSet Foreign_Field_Options DD_INDEXFIELD To DD_NOPUTSet Foreign_Field_Options DD_DEFAULT To DD_DISPLAYONLY

// Child (Client) file structure................Send Add_Client_File Orderdtl.File_Number

// Parent (Server) file structure...............S

end Add_Server_File Customer.File_NumberSend 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_NumberSet Field_Options Field Orderhea.Order_Number To DD_AUTOFIND





Set Field_Prompt_Object Field Orderhea.Order_Number To (ORDERHEA_SL(Self))Set Key_Field_State Field Orderhea.Order_Number To TRUESet Status_Help Field Orderhea.Order_Number To "Order Number - New orders are

assigned numbers automatically"

// Orderhea.Customer_Number

// Orderhea.Order_DateSet Field_Class_Name Field Orderhea.Order_Date To "dbSpinForm"Set Field_Entry_msg Field Orderhea.Order_Date To Entry_Order_DateSet Field_Mask Field Orderhea.Order_Date To "mm-dd-yyyy"Set Field_Mask_Type Field Orderhea.Order_Date To MASK_DATE_WINDOWSet 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_ViaSet Field_Class_Name Field Orderhea.Ship_Via To "dbComboForm"Set Field_Value_Table Field Orderhea.Ship_Via To (Ship_Table(Self))Set Status_Help Field Orderhea.Ship_Via To "Shipping method"

// Orderhea.Ordered_By //DDB/ Comment_Short Field Orderhea.Ordered_By To "This is just a suggested list. Noparent files support this"

Set Status_Help Field Orderhea.Ordered_By To "Order placed by"

// Orderhea.Salesperson_IdSet 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_WINDOWSet 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-DefineFieldEndEnd_Procedure // Define_Fields

El constructor de “Define_Fields” puede usarse solamente en clases. No puede crear o aumentar “Define_Fields” dentro de un DDO.






Definir clases de Diccionario de Datos.





Definir los atributos de tabla dediccionario de datosLos atributos de tabla de diccionario de datos definen los atributos que son aplicables a la tablaentera. Estos atributos son:

• Fijar su tabla principal (Set Main_File).

• Definir sus campos clave (Key Fields).

• Definir las protecciones de grabación 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 puestono pueda ser cambiado. Poner esta propiedad es el requisito mínimo de un Diccionario de Datos.La clase de Diccionario de Datos más básica podría ser creada de la siguiente manera:

Class cTheMostSimpleCustomer_DD is a DataDictionaryProcedure Define_Fields

Forward Send Define_Fieldsset Main_File to MyTable.File_Number

End_ProcedureEnd_Class


Definir los atributos de tabla de Diccionario de Datos.

Campos clave (key Fields)

Set Protect_Key_State to trueSet 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 campoclave es “Key_Field_State”.





Una vez designados los campos clave puede fijar opciones para todos ellos conForeign_Field_Options.

Key_Field_State

Set Key_Field_State Field Customer.Id to trueKey_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 elcampo, es decir, no se pueden modificar los datos de un campo clave. Esto se conoce comoprotección de campo clave (Key Field Protection). La protección de campo de la clave primariaevita que los datos de los campos que componen la clave primaria se modifiquen una vez que elregistro sea creado (por ejemplo: si la clave primaria de una tabla de clientes es cliente.código no

interesaría modificar el código una vez que ya se haya creado el cliente).

Generalmente pondría esta opción sobre campos de claves primarias como el campo de númerode pedido en una tabla de cabecera de pedido o el campo de identificación del cliente en la tablade clientes. Esto proporciona protección de orfandad impidiendo que sean modificados los camposde identificación usados en las relaciones “padre/hijo”.

Si su clave primaria consta de varios campos, todos los campos de la clave deben ser marcadoscomo campos clave.

Los campos clave solamente están protegidos en una tabla si la propiedad de “Protect_Key_State” también 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” después de que hayan sido grabados por primera vez en un nuevo registro.

Cuando estén marcados a verdadero (true), un campo identificado como parte de una clave nopuede ser editado después de que haya sido grabado. Esto asegura que los “registros hijo” quese relacionan con un “registro padre” a través de una clave primaria, no se puedan por cualquiercasualidad dejar “huérfano”.

Los campos que componen una clave primaria son identificados usando la propiedad de campo “Key_Field_State”.







Protección de grabación 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 directamentepara grabar o borrar registros. Esto quiere decir que los mensajes “Request_Save” y

“Request_Delete” enviados al DDO generarán un error y no llevarán a cabo ninguna actualización.

Note que los registros en un Diccionario de Datos de solo lectura (Read_Only) pueden sermodificados o borrados indirectamente por mensajes enviados a otro Diccionario de Datos dentrode estructuras de objeto. Por ejemplo, si el DDO padre es la tabla de cliente y esta se marca comode solo lectura (Read_Only) y el DDO de la tabla de cabecera de pedidos no se marca como desolo lectura (Read_Only), entonces las grabaciones y borrados enviados al DDO de cabeceras depedidos permitirán modificar estos datos de la tabla de clientes. Esto es necesario para mantenerla 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 más probable que se fije en un objeto de Diccionario de Datos y no en unaclase.

No_Delete_State

Set No_Delete_State to True

No_Delete_State desactiva borrados directos de los registros. Esto quiere decir que el mensajeque “Request_Delete” enviado a este DDO generará un error y no llevará a cabo ninguna acción.

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 cómo afecta una orden de borrados (delete) a los registrosrelacionados de una tabla hijo, cuando el borrado se envía al “padre”.

Si Cascade_Delete_State es verdadero, entonces los registros de la tabla hijo y todos losregistros descendientes serán eliminados.

Si la propiedad está a falso, se permitirá el borrado cuando no exista ningún registro “hijo”.

Ambos métodos aseguran que ese registro “hijo” nunca se deje huérfano.





Validate_Foreign_File_State

Set Validate_Foreign_File_State to False

Antes de que ocurra una grabación, querrá validar todos los campos y esto lo puede hacerenviando el mensaje Request_Validate al DDO que va a llevar a cabo la grabación. Normalmentetodos los campos de todas las tablas que participan en una grabación serán validados. Estoincluye campos que no tengan representación visual en la vista en curso y todos los campos entodas las tablas ascendentes (ejemplo: en una jerarquía nieto-padre-abuelo, nos referimos a lastablas “padre” y “abuelo” en relación al nieto). En casi todos los casos, se desea este nivel deprotección de datos, y es potente característica del Diccionario de Datos. También en casosinfrecuentes puede seleccionar niveles inferiores de protección de validaciones.

El “Validate_Foreign_File_State” de propiedad determina si la validación de campo se debe aplicar

a tablas foráneas (padre). Normalmente, querrá este nivel de validación por lo que el valor pordefecto es verdadero. Configurar que su valor sea falso pasará por alto la validación de campocuando la tabla sea usada como una tabla “padre” en una estructura de DDO. Esto hará que sesupriman las validaciones en todas las tablas ascendentes.

Poner esta propiedad fuera de los valores por defecto ignora la validación de campo ycompromete la integridad de datos. Solamente deben ser usados bajo circunstanciascuidadosamente controladas.

No use esta propiedad cuando busque soluciones rápidas para el diseño de base de datos. Lasreglas especiales de validación condicionales pueden ser programadas directamente en susrutinas de validación. Por ejemplo, podría desarrollar una rutina de validación que solamenteaplicase una validación de campo a nuevos registros (verificar el estado con la propiedad de

HasRecord del registro) o bien, podría crear rutinas de validación que pasasen por alto ciertoscampos de forma selectiva cuando son foráneas (la variable global de tipoEntero_Integer_Operation_Origin nos dice que DDO empezó la grabación). En vez de romper unaregla, intente definir este cambio de regla como parte de su conjunto de reglas. Al final, tendráuna mejor solución en todos los aspectos.







Definir los atributos de campo dediccionario de datosLos atributos de campo permiten que defina la información extensiva sobre cada campo en sutabla. Cuando desarrolle su aplicación, esta información será usada por el Studio y sus asistentes(wizards) para automatizar gran parte del proceso de desarrollo. Cuando ejecuten su programa,esta información será usada para ayudar con la navegación, 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).

• Métodos de entrada y salida de campo (Field Entry and Exit Methods).

• El incremento automático 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. Estasalternativas condicionan la variedad de atributos incluyendo encontrar los comportamientos (ej.Búsqueda automática “auto-find”, búsqueda requerida “find-required”…), los comportamientos deentrada de datos (ej. Siempre mayúsculas “Capslock”…) y comportamientos de actualización (No-Put, Force-Put). Estas opciones se definen con varias constantes de “DD” y se enumeran acontinuación.

Las alternativas mostradas abajo con un asterisco (*) son opciones de Búsqueda y pueden usarsesolamente sobre campos indexados. Las otras opciones pueden ser empleadas con cualquiercampo, con la excepción de campos extensos (Extended Fields).

Auto-Find DD_AutoFind *

Auto-Find GE DD_AutoFind_GE *

Uppercase DD_CapsLock

Display-Only DD_DisplayOnly

Find-Required DD_FindReq *

Force-Put DD_ForcePut





No-Enter DD_NoEnter

No-Put DD_NoPut

Retain DD_Retain

Retain-All DD_RetainAll

Required DD_Required

Skip-Found DD_SkipFound

Zero-Suppress DD_Zero_Suppress

Por ejemplo, podría definir que un campo fuera Not-Put, Auto-Find y CAPSLOCK fijando lassiguientes propiedades:

Field_Options field Customer.Id to DD_NoPutSet Field_Options field Customer.Id to DD_AutoFindSet Field_Options field Customer.Id to DD_CapsLock

Debido a que a menudo hay opciones múltiples que deben ser aplicadas al mismo campo, se lepermite combinar múltiples opciones en una sola línea 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 anivel de objeto, no podrá usar el mensaje de “Field_Options”. En vez de esto podrá usar

“Field_Option” (fíjese que va en singular),” Field_Option_Clear” y “Field_Option_Toggle”. Paramás información vea “Cambiar propiedades de campo dentro de DDO”.

Set Field_Option field Customer.State to DD_RetainSet Field_Option_Clear field Customer.State to DD_RetainSet Field_Option_Toggle field Customer.State to DD_Retain

Búsqueda automática (DD_AutoFind)

Set Field_Options field Customer.Id to DD_AutoFind

DD_AutoFind ejecuta una búsqueda automática por el índice principal (Main Index) del campo.Esta opción no funciona en un campo que no tenga índice principal.





Si se encuentra un registro cuyo valor en el índice principal concuerda exactamente con losvalores de los Forms de entrada, se muestran los datos del registro. Si no se encuentra ningúnregistro, el cursor sale del Form de manera normal y no se mueve ningún registro al Buffer. No se

declarará ningún error.

Generalmente pondría esta opción 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 últimocampo que participe en el índice.

Si lo usa conjuntamente con Find_Required, Auto-Find exigirá al usuario que introduzca una claveque exista antes de continuar.

Búsqueda automática GE (DD_AutoFind_GE)

Set Field_Options field Customer.Id to DD_AutoFind_GE

DD_AutoFind_GE lleva a cabo una búsqueda GE (mayor o igual a) por el índice principal de campoal 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 concuerdaexactamente con los valores de los Forms de entrada, se muestran los datos del registro. Si no seencuentra ningún registro igual al que se está buscando, se busca el siguiente por ese índice yese es el que se muestra.

Auto-Find GE es útil para encontrar por anotaciones parciales a elementos o en índices con variossegmentos 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 deidentificación del registro).

Puede usar “AutoFind-GE” en cualquier campo tanto si el índice principal de campo es único o sino lo es.

Si está empleando “Auto-Find GE” en un índice multi-segmento, ponga la opción de “DD_AutoFind_GE” en el último campo del índice para el que desee introducir valores. Si cualquiercampo que se antepone a uno con la alternativa de “DD_AutoFind_GE” en el índice, carece de unvalor de entrada en su Form, el valor de ese campo será considerado vacío para los propósitos dela búsqueda. El registro encontrado será uno cuyo valor para el primero en ese campo sea el más

bajo en el índice

Si quiere ejecutar una búsqueda automática para encontrar una coincidencia exacta igual a (EQ)usa la opción AUTO_FIND.

Auto-Find GE encontrará siempre un registro, a menos que la tabla esté vacía.

UPPERCASE (DD_CapsLock)

Set Field_Options field Customer.Id to DD_CapsLock





DD_CapsLock cambia, automáticamente, cualquier carácter que la entrada haya relacionado conel campo (en letras mayúsculas). No tiene efecto en los caracteres no-alfabéticos. Esto garantizaque todos ingresen datos en la entrada con letras mayúsculas.

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 bufferde registro de la tabla antes de una grabación incluso si no se ha hecho ningún cambio.

Normalmente los contenidos de los Forms de entrada de datos, solo se ponen en El buffer si han

sido cambiados en relación 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 introducción de datos a través de cualquier Form asociado con el campo.

Nota especial:

La opción Skip-Found (DD_SkipFound) tiene un efecto similar, excepto que permite que el cursor

vaya a ese elemento si no se encontró ningún registro. No-Enter pasa por alto el Form sinconsiderar si se encuentra un registro.

La alternativa DD_DisplayOnly es una combinación 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 serán pasados al buffer ygrabados, 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 delcampo, incluso si se han introducido datos nuevos vía teclado. No-Put es útil para permitir que seintroduzcan datos en un Form donde no desee permitir que se modifique el campo.

Use la opción “No-Put” cuando quiera impedir que los usuarios cambien los datos.

La alternativa DD_DisplayOnly es una combinación de DD_NoEnter y DD_NoPut.





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 estecampo e impide que se modifique cualquier dato. El Form se mostrará como desactivado.

DD_DisplayOnly es equivalente a la combinación de DD_NoEnter y DD_NoPut.

// This is the same as DD_DisplayOnlySet 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(vacíen) cuando el usuario inicia una operación que normalmente limpiaría todos los Forms deuna vista.

Si el usuario inicia la operación clear-all, entonces no se conservará absolutamente ningún dato.

Es algo que habitualmente no se puede aplicar a todos los objetos en todas las vistas que usenuna clase DD en concreto. En vez de eso, la opción de mantener (Retain) se debería basar en losrequisitos específicos de entrada de datos de una vista. Por lo tanto se espera que Retain seaaplicado en nivel de objeto de DD y no como parte de la definición 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

(vacíen).

Aunque los usuarios no puedan limpiar el Form, la entrada de datos sí podría hacerlomanualmente borrando carácter a carácter presionando la tecla “Limpiar”.

Es algo que habitualmente no se puede aplicar a todos los objetos en todas las vistas que usenuna clase DD en concreto. En vez de eso, la opción de mantener (Retain) se debería basar en losrequisitos específicos de entrada de datos de una vista. Por lo tanto se espera que Retain seaaplicado en nivel de objeto de DD y no como parte de la definición de clase.





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 elbuffer para la tabla tiene un registro activo.

DD_NoEnter es una opción de campo similar. Sin embargo, pasa por alto el Form de base dedatos 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 numérico con valorcero (0).

DD_Zero_Suppress parecerá no funcionar en donde haya un valor absoluto pequeño en un Form.Por ejemplo, si un Form especifica valores enteros de visualización y un valor de campo inferior a1 (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 carácter o caracteres que se introduzcan en el Form de entrada de datos permitirán queel cursor se mueva al siguiente Form.

Este requisito se aplicará también durante la validación de grabación.

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 seencuentre un registro válido del campo asociado al Form. Una búsqueda fallida causa un Error 90(por favor introduzca un registro válido).

“Find required” no tiene ningún efecto si un registro activo para la tabla ya está en la vista.





Normalmente aplicaría Find Required como una opción de campo foráneo (Foreing-Field) en una “tabla padre” para asegurarse que se encuentra un registro relacionado antes de que ocurra unagrabación en la “tabla hijo”.

Una opción de Auto-Find en el campo con Find Required intentará encontrar el registroautomáticamente cuando un usuario intente mover el cursor fuera del Form. Si la búsquedaautomática 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 numérico con valor cero).

“Find Required” con Auto-Find GE es innecesario. Auto Find GE siempre encuentra un registro enuna tabla que no esté vacía.

Este requisito de búsqueda se aplicará también durante la validación de grabación.

Limpiar opciones de campo

Se soportan mensajes opcionales para permitir que se limpien o alternen ciertas opciones deelementos:

Field_Option_Clear (y File_Field_Option_Clear) limpia las opciones de campo pasadas por estemensaje

Set Field_Option_Clear Field Customer.Name to DD_Retain

Field_Option_Toggle (and File_Field_Option_Toggle) alternan las opciones de campo pasadas poreste 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 seemplearán en los DDOs para controlar dinámicamente una vista de entrada de datos. Vea

“Cambiar propiedades de campo con DDOs” para más información.


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 valorválido. Se puede definir uno de los cuatro tipos de validaciones de campo:

• Casilla de verificación (Checkbox): debe ser uno de dos valores, generalmente, verdadero ofalso.

• Rangos (Range): el valor introducido debe de estar dentro de un rango de números ofechas.





• Verificación (Check): el valor introducido debe encajar “match” con un elemento de unacadena de verificación. Una cadena de valores válidos separados por el carácter "|".

• Tabla de validación: el valor introducido debe encajar “match” con un valor de un objeto deuna tabla de validación. Una tabla de validación especial llamada “tabla de validación declave” (Code Validation Table) provee una manera fácil de atribuir un juego de las claves ydescripciones válidas a cualquier campo.

Además, para cualquier campo puede definir un método personalizado de validación (FieldValidation Method). Este método, una función, se asigna a un campo fijando el mensaje devalidación de campo (Field Validation Message). Esta función se llama durante la validación. Si sedetecta un error, la función debe generar uno y devolver un valor distinto de cero. Esta funciónpermite que cree cualquier tipo de regla de validación que necesite.

La validación de campo ocurre durante la navegación hacia delante (Forward Navigations) y lasparadas. Usar validaciones de campo asegura que los datos que se están grabando en su base de

datos son válidos.

Casilla de verificación (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 deverificación (Checkbox). Un campo de casilla de verificación puede almacenar uno de dos valores,un valor verdadero y uno falso.

Si el campo se representa con una casilla de verificación (dbCheckbox), el control estará marcadocuando el campo con el que el valor se compare sea verdadero. Estará desmarcado cuando elcampo 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 validación, el número de error y el texto especificado para el campo en lapropiedad de “Field_Error” se usan para informar del error. Si no se define ningún texto, seinforma con el texto de error estándar.

Rangos (Range)

Set Field_Value_Range.field Customer.discount to 0 60

El método de “Field_Value_Range” permite definir un valor mínimo y máximo para el campo. Elcampo y sus rangos deben ser numéricos o fechas. El valor “Desde” debe ser inferior al del

“Hasta”.

La validación se lleva a cabo después de que el usuario haya introducido los datos en el Form deentrada de datos del campo. Si falla la validación, entonces el usuario no podrá dejar el Form. (Elusuario todavía puede salir del Form haciendo clic con el ratón en otro lugar de la pantalla).





Cuando ocurre un error de validación, el número de error y el texto especificado para el campo enla propiedad de “Field_Error” se emplean para informar sobre el mismo. Si no se define ningúntexto, se informa con el texto de error estándar.

La validación también se lleva a cabo cuando se graba un registro. Si falla la validación, sesuspende la grabación.

Verificación (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 válidos está limitada a un juego estático y pequeño de valores. Estas muestras están identificadas en una cadena de

comprobación (Check String). Esto consta de una lista de valores válidos separados por elSímbolo "|". Por ejemplo, para posibles valores válidos A, B, C, se usaría la cadena “A|B|C”,mientras que para valores válidos Po, Ou, Lu se representaría con la cadena “Po|Ou|Lu”

La validación se lleva a cabo después de que el usuario haya introducido los datos en el Form deentrada de datos del campo. Si falla la validación, entonces el usuario no podrá dejar el Form. (Elusuario todavía puede salir del Form haciendo clic con el ratón en otro lugar de la pantalla).

Además de usarse para validar, estos valores también pueden usarse con elementos de entradaCombo-Box. Si se asigna un dbComboForm a un campo que usa valores de verificación (Check),cada valor del String de verificación será cargado en la lista de combo (Combo-List).

Set Field_Value_Check field Customer.state to "Po|Ou|Lu|SA"

Quizás el ejemplo de “Customer.state” no sea probablemente una buena muestra de de estemétodo de validación. Añadir nuevas provincias a esta lista requiere cambios de programa, y elString puede ponerse demasiado grande para ser práctico. En ese caso, querrá usar una tabla devalidación (Validation Table).

Cuando hay un error de validación, el número de error y el texto especificado para el campo en lapropiedad de “Field_Error” se usan para informar del error. Si no se define ningún texto, seinforma con el texto de error estándar.

La validación de verificación (Check) es limitada. Una manera más flexible y reutilizable de

especificar una lista de entradas válidas es usar una Tabla de Validación.

Tablas de validación (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 devalores, o con un rango de valores, puede usar la casilla de verificación (Checkbox), Rangos(Rango) o Validaciones (Check). En muchos casos descubrirá que estas clases de validaciones





son demasiado limitadas para sus necesidades. En ese caso, puede usar tablas de validación decampo.

Usar una tabla de validación de campo tiene las siguientes ventajas:• Especificar un número más grande de valores válidos de los que puede encajar en una

cadena de valores válidos.

• Especificar y mostrar una descripción para cada valor.

• Puede mantener actualizada su lista de valores (los valores no tienen que ser codificadosdirectamente en su programa).

• Puede hacer las elecciones de lista opcionales (puede sugerir una lista de valores durante laintroducción de datos pero a los usuarios no se les exiges hacer una selección de la lista).

Cuando ocurre un error de validación, el número de error y el texto específico para el campo en lapropiedad de “Field_Error” se emplean para informar sobre un error. Si no se define ningún texto,

se informará con un texto estándar.

El uso de tablas de validación da una flexibilidad tremenda. Más adelante se hablará con detallede cómo usar tablas de validación. Por ahora abordaremos el tema de las clases primarias deTablas de Validación:

Tabla de validación (Validation Table)

Esta clase permite que mantenga actualizada una lista de valores válidos.

Object oStatusTable is a ValidationTableProcedure Fill_List

Send add_table_value "O"Send add_table_value "C"Send add_table_value “D”

End_ProcedureEnd_Object

Descripción de validación de tabla (Description Validation Table)

Esta clase permite que mantenga actualizada una lista de valores válidos y sus descripcionesasociadas.

Object oStatusTable is a DescriptionValidationTableSet 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”






Tabla de validación de archivo (File Validation Table)Esta clase le permite mantener actualizada una lista de valores y descripciones que puede serfácilmente cargado desde una tabla Visual DataFlex específica.

Object StatusTable is a FileValidationTableSet Main_File to CustStat.File_Number

End_Object

Tablas de validaciones de código (Code Validation Table)

Esta clase permite que cargue sus valores de datos y descripción de la lista de claves de VisualDataFlex (Visual DataFlex Code List)

Object oStatusTable is a CodeValidationTableSet Type_Value to "Status"

End_Object

Cualquiera de las tablas de validación de arriba puede ser conectada a un campo con el mensajede “Field_Value_Table en un Diccionario de Datos.

Set Field_Value_Table Field Customer.Status to oStatusTable

Métodos de validación 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 campodebe ser validado. Este mensaje será el mensaje Id de una función y se llama cuando el programa

necesita una validación. Este método de validación se usa cuando tiene que llevar a cabovalidaciones complejas que pueden ser expresadas solamente con código. Debido a que es unproceso muy abierto, puede hacer prácticamente cualquier cosa. Si el valor es válido, la funcióndebe devolver un cero. Si el valor no es válido, la función debe generar un error y devolver unvalor distinto de cero.

Este método de validación puede usarse en conjunto con otras técnicas de validación (casilla deverificación-Checkbox; Rangos-Range; Verificación-Check o Tabla de Validación-Table Validation)o como una sustitución de ellos.

Deberá crear la función(s) de validación (s). Esta función pasa el número de campo y el valor delcampo. La función puede usar estos valores cuando sea conveniente. Para este propósito, el valorde cualquier otro campo en el Diccionario de Datos puede ser obtenido mediante la propiedad de





“Field_Current_Value”. Es importante notar que la rutina de validación nunca necesitará acceder aun valor de un DEO. La información necesaria deberá poder ser encontrada en el DDO o en unode los DDOs conectados con ella.

Por ejemplo, si tiene la siguiente función:

Function ValidateCredit Integer iField Number nValue ;Returns Boolean

Boolean bErrString sCustRating

// get the customer rating for this customer from DD bufferGet Field_Current_Value field Customer.Rating to sCustRating

// If customer Rating is A1 their limit is 5000If (sCustRating = "A1" and nValue> 5000) Begin

Error DFERR_OPERATOR "Credit limit may not exceed $5000"Move True To bErr

End

Function_Return bErrEnd_Function

Para usar esta función en el campo “Credit_Limit” de una tabla, debe establecer el método devalidación (Field_Validate_msg) al “Handle Name” de la función. El “Handle Name” de una función

es el nombre de la función con el prefijo “Get” (por ejemplo: Get_ValidateCredit). SetField_Validate_msg field Customer. Credit_Limit to get_ValidateCredit

El prototipo de declaración para un método de validación tiene la siguiente forma.

Function_function_name integer iField type CurrentValue returns integer

Dónde:

• Function_name es el nombre de la función de validación;

• iField es el número de campo del campo que envió function_name. El número de campopuede ser usado para recuperar cualquier información 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 validación de métodos generalizados que pueden serusados por otros campos y tablas.

Errores de validación de campo (Field Validation Errors)

Set Field_Error field Customer.Credit_Limit to 200 Not a legal number"





El método Field_Error permite definir un número de error específico y enviar un mensaje siempreque la validación falle para el campo. Esto quiere decir que cada campo puede tener su propiomensaje de error de validación específico.

El error es lanzado cuando una de las siguientes pruebas de validación falla: casilla deverificación-Checkbox; Rangos-Range; Verificación-Check o Tabla de Validación-Table Validation.Los métodos de validación deben tener sus propios textos de error codificados dentro de lafunción.


Definir los atributos de campo de Diccionario de Datos.

Aspecto del campo

Máscaras (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 máscaras se emplean en las aplicaciones Windows de Visual DataFlex para:

• Restringir la entrada de datos en un campo a un patrón definido de números, letras o

caracteres de puntuación.• Proveer la visualización de los datos de un campo de acuerdo a formatos y patrones

predefinidos. Por ejemplo, es posible mostrar valores de fecha con las abreviaturas comodías de la semana o meses del año. La traducción de números a nombres es sensible a laConfiguración Regional de Windows

Las máscaras no son la validación y no deben ser usadas como una técnica de validación.

Las máscaras se definen poniendo dos propiedades de campo: “Field_Mask_Type” y “Field_Mask”.

Las máscaras se comentan con más detalle en “Máscaras 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 cortasse definen usando las propiedades de “Field_Label_Long” y “Field_Label_Short”.

Cuando obtenga el valor de una etiqueta deberá usar la función “Field_Label”.





Get Field_Label Field DD_LABEL_SHORT to sHeaderNameGet Field_Label Field DD_LABEL_LONG to sLabel

La función “Field_Label” (y File_Field_Label) nos facilita flexibilidad adicional en determinar elvalor de una etiqueta.

• Si se pide el valor de la etiqueta larga y no se ha asignado el nombre de etiqueta larga, seobtiene el nombre del campo.

• Si se pide el valor de la etiqueta corta y no se ha asignado el nombre de etiqueta corta, seobtiene el nombre de etiqueta largo.

Se aplica la misma lógica cuando el Studio o los asistentes (Wizards) se usan para diseñar vistase 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 decolumna (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 línea de texto de ayuda para el campo. Los objetos de entrada la usanpara mostrar la ayuda en la barra de estado. Cuando el usuario cambia el cursor, un objeto deentrada de datos muestra la ayuda “Status Help” en la barra de estado.

Introduzca el texto que ayude al usuario con información 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 específico a cada campo. Pordefecto, Studio usará esta información para determinar la clase del control que se crea siempreque el campo sea arrastrado en un componente. Este ajuste no evita que elija una clase decontrol diferente para el campo de una forma explícita en el Studio, o para cambiar la clase delcontrol 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. ElStudio hace un buen trabajo al asignar el control correcto así que esta propiedad se dejará,generalmente, vacía.

Puede asignar cualquier nombre de clase en este Form. Si pone en el nombre de una clase noestándar, entonces la clase debe ser registrada correctamente en Studio antes de que pueda serusado.







Métodos de entrada y salida

Las propiedades de “Field_Entry_msg” y “Field_Exit_msg” son similares al “Field_Validate_msg” yson enviadas siempre que el cursor entre o salga de un elemento conectado con un campo.Crearía los procedimientos y luego atribuiría los nombres de procedimiento (procedure) a laspropiedades de campo. Cuando se llaman se pasa el número de campo y el valor del campo. Alprocedimiento (procedure) mientras devuelva un valor distinto a cero se podría parar lanavegación, esto sería un uso anormal o poco habitual. Estos procedimientos se emplean,generalmente, para manejar procesos antes de entrar y después de salir.

Método de entrada

Set Field_Entry msg Field Customer.State To EntryCustomerState

“Field_Entry_msg” permite que especifique el nombre de un método que se ejecuta siempre queel cursor se mueve un Form de entrada de datos conectado al campo.

El método de entrada, un procedimiento, puede ser programado para llevar a cabo cualquieracción. Podrá usarlo para mostrar información especial o valores por defecto cada vez que elcursor vaya al campo.

En Visual DataFlex, los procedimientos pueden devolver un valor entero. En el caso de un métodode entrada (Entry method), si se devuelve un valor distinto de cero, se aborta la entrada delcursor al Form. Usar los métodos de entrada para controlar la navegación es muy desaconsejable.

El método 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 blankBoolean bChanged

Get Field_Changed_State iField to bChangedIf (not (bChanged) AND dDate = 0) BeginS

ysDate dDateSet Field_Default_Value iField to dDate

EndEnd_Procedure

Para usar este procedimiento en un campo fecha de una tabla, pondría el método de entrada de

campo a “EntryOrderDate”. Estaría asignando el manejador de método “msg_EntryOrderDate”

pero si se omite el prefijo "msg" este será proporcionado automáticamente.





Set Field_Entry_msg Field Orderhea.Order_Date To EntryOrderDate

El prototipo de declaración para un método de entrada tiene el siguiente formato general.

procedure procedureName integer iField type currentValue

Dónde:

• procedureName es el nombre del procedimiento;

• iField es el número de campo del campo que envió “procedureName”. El número de campopuede usarse para obtener cualquier información sobre el campo.

• Type y currentValue son el tipo y el valor actual del campo que envió “procedureName”.

Los parámetros que se pasan al método de entrada permiten que escriba procedimientosgeneralizados que pueden ser reutilizados en otros campos y tablas.

Método de salida

Set Field_Exit_msg Field Customer.Zip To ExitAdjustZip

“Field_Exit_msg” permite que especifique el nombre de un método que se ejecute siempre que elcursor se va de un Form de entrada de datos conectado al campo.

El método de salida, un procedimiento, puede ser programado para llevar a cabo cualquier acción.Por ejemplo, podría usarlo para ajustar valores de algunos datos calculados que están en funcióndel valor del campo introducido.

En Visual DataFlex, los procedimientos pueden devolver un valor entero. En el caso de un métodode salida, si se devuelve un valor distinto de cero se aborta la acción de salir del Form de entradade datos. No se recomienda utilizar este evento para controlar la navegación.

El método 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 iQtyNumber nAmntGet Field_Current_Value Field Orderdtl. Qty_Ordered to iQtyGet Field_Current_Value Field Orderdtl.Price to nAmntSet Field_Current_Value Field Orderdtl. Extended_Price to (nAmnt * iQty)

// note we set value, but not changed state!End_Procedure





Para usar este procedimiento sobre el campo apropiado de una tabla, pondría el método deentrada del campo a “AdjustDisplayTotal”. Estaría asignando el manejador de método

“msg_AdjustDisplayTotal pero si se omite el prefijo “msg” este será proporcionado

automáticamente.

Set Field_Exit_msg Field Orderdtl.Qty_Ordered to Adjust_Display_Total

El prototipo de declaración para un método de salida tiene el siguiente formato general.

procedure procedureName integer iField type currentValue

Dónde:

• procedureName es el nombre del procedimiento;• iField es el número del campo que envió “procedureName”. El número de campo puede

usarse para obtener cualquier información sobre el campo.

• Type y currentValue son el tipo y el valor actual del campo que envió “procedureName”.

Los parámetros que se pasan al método de salida permiten que escriba procedimientosgeneralizados 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 unaidentificación única al registro. Esto sería la clave primaria. En algunos casos, el valor de la claveprimaria debe ser introducido manualmente por el operador (Ej. Introducir una identificación decadena única como parte de la entrada de datos). En algunos casos, la base de datos suministrarála calve primaria automáticamente al grabar el registro. En otros casos, el Diccionario de Datosdebe suministrar esta identidad única cuando se grabe el registro por primera vez.

El autoincremento (Auto-Incremento) del Diccionario de Datos nos da esta funcionalidadasignando números automáticamente y de forma secuencial a cada nuevo registro.

Para que el Diccionario de Datos sepa cuál es el siguiente número a un nuevo registro debemosalmacenar el último número 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 ausar para almacenar ese número así como el campo ID (clave primaria) en su Diccionario deDatos. Para facilitar esta operación existe un comando llamado Define_Auto_Increment

Define_Auto_Increment ordsys.last_cust_num to Customer.cust_number





En este ejemplo, el campo Ordesys.Last_Cust_Num tabla sistema se designa para incrementar ysuministrar un valor al campo cust_number de la tabla Customer.

El autoincremento funcionará correctamente solo si la tabla externa es una tabla de sistema (unsolo 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 elejemplo anterior con cust_number. Si está usando un campo de una tabla sistema, tiene queregistrar esta tabla como una tabla externa de forma que se bloquee correctamente duranteoperaciones de grabación. Por ejemplo:

Define_Auto_Increment ordsys.last_cust_num to Customer.cust_numberSend Add_System_File ordsys.last_cust_numDD_LOCK_ON_NEW_SAVE_DELETE

Puede usar una “tabla padre” relacionada si su identificador (ID) único es multi - segmento. Porejemplo el ID de una estructura Cabecera-Detalle como en pedido-detalle pedido. Por ejemplo, elID de una tabla de Detalle (Order-Detail) en una estructura Cabecera-Detalle (header-detail)podría ser el número del documento (Cabecera) y un número de orden de detalle asignado poruna tabla sistema. Si el último número de detalle de cada cabecera fuera almacenado en la tablaCabecera (OrderHea.Last_Detail_Num) el campo de Autoincremento se definiría 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 autoincrementoadicional dentro de su Diccionario de Datos puede hacerlo fácilmente añadiendo un códigopersonalizado 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 fácil en su aplicación.Típicamente cada tabla tendrá al menos una lista de consulta relacionada con ella. Las columnasen esta lista de consulta contarán, a menudo, con los campos más importantes de su tabla. Estoscampos se ponen normalmente en un índice y las listas de consulta se diseñan para dejar buscarregistros fácilmente 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 fijarán esas listas deconsulta a todos los objetos de introducción de datos que usan ese campo de forma automática.





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 deasignarlo. 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 validación (casilla de verificación, rango, tabla de verificación ovalidación) es capaz de suministrar una lista de consulta por defecto; lo hace si no tiene unaasignada explícitamente. Así que si asigna a un campo un “Field_Prompt_Object”, este se usaráen vez de la lista suministrada para las validaciones extendidas.







Definir atributos de camposforáneos en Diccionario de DatosDentro de su DEO (Objeto de entrada de datos) el comando Entry_Item une una tabla y el valordel campo a un form o a una columna de una parrilla (grid). Esta tabla será la tabla principal delDiccionario de Datos del DEO, o la tabla “padre”. Cuando se use como una tabla padre, elEntry_Item se considera conectado con un campo foráneo. Es importante comprender el conceptode un campo foráneo. El siguiente ejemplo muestra un “Entry-Item” que no es foráneo seguidopor uno que si lo es:

// Part of an order entry view //Object oOrderNumber is a dbForm

Set Server to oOrderhea_DDEntry_Item Orderhea. Order_number //this is not a foreing field:

Object oCustomerName is a dbFormSet Server to oOrderhea_DDEntry_Item Customer.Name/ this is a foreing field:

Un ejemplo de un campo extranjero es el campo “customer.Name” cuando sale en un view delOrder Entry. Esto es debido a que es la tabla Order-Header la que provee el servidor deDiccionario 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_DDEntry_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 campoforáneo porque en este caso la tabla del cliente provee el servidor de Diccionario de Datos.

Cuando el número de la tabla (File-Number) de Entry_Item no es el mismo que el número de latabla principal del Diccionario de Datos, la tabla debe ser un antepasado (padre, abuelo,etcétera.). Si no lo es, probablemente, ha cometido un error.

Los elementos de entrada de datos de tablas de ancestros (tablas padre, abuelo…) se usangeneralmente de forma diferente a la entrada de datos de la tabla principal. Cuando se introduceun registro nuevo en la principal, los registros de la tabla padre no se modifican. Su función esproporcionar valores de campo (número de cliente, forma de pago…) en los que se basan lasrelaciones de la tabla principal a la tabla padre. Cuando se tiene que modificar la tabla padre





(añadir, modificar, borrar) dicha modificación se realiza en una vista diferente en la que la tabla(padre) es la tabla principal del DDO.

Debido a esto, los campos foráneos requieren, a menudo, ajustes de opción de campo adicionales.Las opciones de campo foráneos pueden ser atribuidos a campos individuales aunque estoraramente se hace ya que hay multitud de formas más convenientes de hacerlo. Los camposforáneos pueden ser divididos en tres categorías. Éstas son:

• Campos Clave (Key Field): es cualquier campo para el que la propiedad deKey_Field_State es verdadero (Clave primaria).

• Campo Indexado (Indexed Field): es cualquier campo que no es un campo clave y esun segmento en uno o más de los índices de la tabla.

• Campo por defecto (Default Field): es cualquier campo que no es un campo clave o uncampo indexado.

Definiendo opciones de campo foráneos para cada uno de estas categorías de campos(DD_KEYFIELD, DD_INDEXFIELD, DD_DEFAULT) proporciona a sus aplicaciones de introducción dedatos los elementos necesarios sin programación adicional.

Las propiedades de campo foráneos se añaden cualquier propiedad de opción regular de campo.Los siguientes ejemplos indican un uso típico de opciones de campo foráneas.

Set Field_Options field Customer.id to DD_NoPut DD_AutoFind DD_CapsLockSet Field_Options field Customer.balance_due to DD_DisplayOnly:

// define default foreing field optionsSet Foreign_Field_Options DD_KEYFIELD to DD_FindReq

Set Foreign_Field_Options DD_INDEXFIELD to DD_NoPutSet Foreign_Field_Options DD_DEFAULT to DD_DisplayOnly

En este ejemplo, las opciones de campo regulan (campo no foráneo) para “Customer_ID” seránNo-Put, Auto-Find y Capslock. Sus opciones de campo foráneo serán No-Put, Auto-Find, Capslocky puesto que es un campo clave, Find-Required.

Todas las opciones de campo regulares se pueden asignar como opciones de campo foráneos. Enla práctica, las únicas opciones que probablemente vaya a poner son DD_NoPut, DD_NoEnter,DD_DisplayOnly, DD_AutoFind y DD_FindReq.

Campos Foráneos clave

Un campo clave, DD_KEYFIELD, es cualquier campo para el que la propiedad de Key_Field_Statees verdadera. Cuando se usen como campos foráneos, probablemente, querrá que estos campossean Find-Required, Auto-Find y No-Put. Esto quiere decir que debe encontrarse un registroPadre antes de poder grabar el Hijo y que si se introduce un valor en el campo se producirá unabúsqueda automática (Auto-Find) y no se podrá modificar el valor de esta clave; eso si entra enun valor en el que el campo tiene un hallazgo automático y no puede cambiar este valor de tecla.Los ajustes para este campo foráneo serán:





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 estándar de campos se añaden a las opcionesde campos foráneos, únicamente necesitará ajustar:

Set Foreign_Field_Options DD_KEYFIELD to DD_FindReq


Definir Diccionario de Datos y atributos de campos foráneos.

Campos Foráneos indexados

Un campo indexado, DD_INDEXFIELD, es cualquier campo que no sea una clave primaria y quesea un segmento en uno o más índices de la tabla. Cuando se usa como campos foráneos estoscampos son generalmente accesibles (para que pueda llevar a cabo búsquedas manuales) perodefinido como no modificable (No-Put) de forma que no pueda modificar y grabar su valor. Losajustes para este campo foráneo son:

Set Foreign_Field_Options DD_INDEXFIELD to DD_NoPut

Alternativamente, puede incluso decidir el que no se soporte búsquedas en estos campos, encuyo caso los ajustes para estos campos foráneos serán:

Set Foreign_Field_Options DD_INDEXFIELD to DD_DisplayOnly



Campos Foráneos por defecto

Un campo por defectos, DD_DEFAULT, es cualquier campo que no sea una clave primaria o uncampo indexado. No querrá poder cambiar este campo y debido a que no hay índice relacionadocon él, solamente lo podrá ajustar a Display-Only. Los ajustes para este campo foráneo serán:

Set Foreign_Field_Options DD_DEFAULT to DD_DisplayOnly





Definiendo Diccionarios de Datos dePadres, Hijos y relaciones externasLos Diccionarios de Datos tienen que saber cómo 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 información paraverificar que las estructuras de DDO están configurados adecuadamente para operaciones degrabación y borrado.


• Definiendo “tablas padre”

• Definiendo “tablas hijo”

• Requisitos para las grabaciones

• Requisitos para los borrados

• Cómo funcionan las estructuras de DDO de grabación.

• 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(también llamadas “tablas padre”). Identificando todas las “tablas padre” el Diccionario de Datospuede determinar si los DDOs (Objeto de Diccionario de Datos) han sido creados para todos estospadres y si esos DDOs padre están apropiadamente conectados con el DDO principal. El DDOpadre también tiene una lista de “tablas padre” y estos DDOs padre hacen lo mismo paraasegurarse de que sus DDOs padre existen y de que están apropiadamente conectados dentro dela estructura. Este proceso ocurre hacia la parte superior (hacia arriba) de la jerarquía de toda labase de datos.





Propagando esta comprobación hacia arriba se puede verificar si una estructura de Diccionario deDatos está completa. Si la estructura no está completa, ese DDO no podrá grabar o borrarregistros.

La información de la “tabla padre” también es utilizada por el Studio y por varios asistentes paraayudarle a construir sus aplicaciones. Por lo tanto es importante que esta información seamantenida correctamente en su clase de Diccionario de Datos.

Se añaden tablas a la lista de “tablas padre” relacionadas con el mensaje “Add_Server_File”.Envíe 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 están relacionadas con él(también llamadas “tablas Hijo”). Identificando todas las “tablas hijo” el Diccionario de Datospuede determinar si los DDOs (Objetos de Diccionario de Datos) han sido creados para todosestos hijos y si esos DDOs hijo están apropiadamente conectados con el DDO principal. El DDOhijo también tiene una lista de “tablas hijo” y estos DDOs hijo hacen lo mismo para asegurarse de

que sus DDOs hijo existen y de que están apropiadamente conectados dentro de la estructura.Este proceso ocurre hacia la parte inferior (hacia abajo) de la jerarquía de toda la base de datos.

Propagando esta comprobación hacia abajo se puede verificar si una estructura de Diccionario deDatos 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 información de la “tabla hijo” también es utilizada por el Studio y por varios asistentes paraayudarle a construir sus aplicaciones. Por lo tanto es importante que esta información estémantenida correctamente en su clase de Diccionario de Datos.

Se añaden tablas a la lista de “tablas hijo” relacionadas con el mensaje Add_Client_File. Envíeeste mensaje a cada una de las “tabla hijo”.







Requisitos para grabar (save)

El requisito de estructura de DDO para una grabación es simple. Para cada “tabla padre” definidaen el DDO (con el método Add_Server_File) debe estar representado como un DDO en laestructura de objetos y deben estar conectados apropiadamente (con la propiedad DDO_Server).Los siguientes fragmentos de código muestran una clase de Diccionario de Datos y una estructura

de DDO válida que admitiría grabaciones.

Procedure Define_FieldsForward Send Define_FieldsSet Main_File to Orderhea.File_Number:Send Add_Server_File Customer.File_NumberSend Add_Server_File SalesP.File_NumberSend Add_Client_File Orderdtl.File_Number

End_Procedure::

Object oCustomer_DD is a Customer_DataDictionaryEnd_Object // oCustomer_DD

Object oSalesp_DD is a Salesp_DataDictionary

End_Object // oSalesp_DD

Object oOrderhea_DD is a Orderhea_DataDictionarySet DDO_Server to oCustomer_DDSet DDO_Server to oSalesp_DD

End_Object // oOrderhea_DD

Es un caso sencillo. Si cualquiera de los DDOs padre necesitase de padres”, sus DDOs tambiéntendrían que estar presentes antes de permitir una grabación. Por ejemplo, suponga que elDiccionario de Datos del cliente haya sido definido de la siguiente manera:

// Define_Fields in the customer DD classProcedure Define_FieldsForward Send Define_Fieldsset 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 paraCustomer y por lo tanto está incompleta para OrderHea. No se admiten grabaciones en ningunode los dos DDOs. Para que una estructura DDO sea válida necesitaría mostrarse así:





Object oRegion_DD is a Region_DataDictionaryEnd_Object // oCustomer_DD

Object oCustomer_DD is a Customer_DataDictionarySet DDO_Server to oRegion_DD

End_Object // oCustomer_DD

Object oSalesp_DD is a Salesp_DataDictionaryEnd_Object // oSalesp_DD



Note que Add_Server_File se emplea para definir una “tabla padre” requerida dentro de unDiccionario de Datos y que esto ocurre en el nivel de clase. El uso de DDO_Server crea laconexión 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 más complicado. Debido a que losborrados pueden modificar los “registros padre”, la estructura “padre” del DDO debe estarcompleta. Si desea admitir borrados en cascada (el borrado de registros “hijo”) entonces laestructura de su DDO debe contener también todos los DDOs hijos requeridos para poder llevar acabo el borrado en cascada. Por ejemplo:

Procedure Define_FieldsForward Send Define_Fields

Set Main_File to Orderhea.File_Number:Send Add_Server_File Customer.File_NumberSend Add_Server_File Sales.File_NumberSend Add_Client_File Orderdtl.File_Number

End_Procedure::Object oCustomer_DD is a Customer_DataDictionaryEnd_Object // oCustomer_DD






Object oOrderhea_DD is a Orderhea_DataDictionarySet DDO_Server to oCustomer_DD

Set DDO_Server to oSalesp_DDEnd_Object // oOrderhea_DD

Object oOrderdtl_DD is a Orderdtl_DataDictionarySet DDO_Server to oOrderhea_DD


Esta estructura de DDO ahora contiene los DDOs hijos requeridos y, por tanto, los borrados de losregistros de OrderHea serán admitidos. Sin embargo estas estructuras, generalmente, no son tansimples. Si el DDO hijo (OrderDtl) contuviera “tablas padre” adicionales requeridas, entoncestienen que estar presentes esos DDOs hijos y sus respectivos DDOs padres. La estructura de DDOpodría ser:

Object oVendor_DD is a Vendor_DataDictionaryEnd_Object // oVendor_DD

Object oInvt_DD is a Invt_DataDictionarySet DDO_Server to oVendor_DD

End_Object // oInvt_DD





Object oOrderdtl_DD is a Orderdtl_DataDictionarySet DDO_Server to oOrderhea_DDSet DDO_Server to oInvt_DD

End_Object // oOrderdtl_DD







Cómo trabaja la estructura de validación DDO

Cuando se produce una solicitud para grabar o borrar en un Diccionario de Datos, se valida suestructura de objeto y se asegura que todos los “padres” e “hijos” DDOs estén presentes yconectados de forma apropiada. Dependiendo del tipo de operación (“grabar”, “borrado sincascada”, o “borrado con cascada”) se llevarán a cabo diferentes tipos de validaciones. Si laestructura de DDO en curso no está completa para la operación específica, se producirá un error yla operación se suspenderá.

Verificar una estructura de DDO entera para una operación en particular puede ser un procesocomplicado. 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á automáticamente.

Modo de validación

Set Validate_Save_Structure_Mode to DD_VALIDATE_STRUCTURE_ONCESet Validate_Delete_Structure_Mode to DD_VALIDATE_STRUCTURE_ONCE

Hay propiedades que le permitirán modificar la forma validar la estructura de grabar y borrar.Puesto que dentro de una aplicación las estructuras de DDOs son generalmente estáticas,normalmente sólo se tiene que validar la estructura de grabación y borrado una vez. Esto se

efectúa la primera vez que intenta grabar o borrar dentro de ese DDO. Éste es el valor pordefecto.

Dinámicamente tendrá que realizar esta validación cada vez que quiera ejecutar una validación ouna grabación. Aunque esto es poco habitual, está soportado para que lo pueda hacer en loscasos en que los necesite.

También puede desactivar esta validación, pero siempre con precaución.

Esto es un resumen de los modos de validación:

DD_VALIDATE_STRUCTURE_ALWAYS El Diccionario de Datos verificará lasestructuras de tabla cada vez que un

registro se grabe / se borre.DD_VALIDATE_STRUCTURE_NEVER Se desactiva la validación de las

estructuras de la “tabla padre”.

DD_VALIDATE_STRUCTURE_ONCE El error. El Diccionario de Datosverificará las estructuras de tabla laprimera vez que se intente grabardespués de cargar la vista. Esto suponeque la estructura no cambiará durante lasesión - normalmente una suposiciónsegura.





Consulte lo siguienteDefinir relaciones externas Padre-hijo de Diccionario de Datos.

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 desistema que contiene un contador para propósitos de censo asignar claves de identificaciónúnicas. Esas tablas deben ser registradas en el Diccionario de Datos como tablas externas.

Cuando escriba el código en su Diccionario de Datos, que actualice una tabla no relacionadadurante una transacción (Ej. Cuando el DDO está bloqueando tablas y registros), esta tabla sedebe añadir a la lista de tablas externas de la clase de Diccionario de Datos. Esto levantaría loserrores 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 mensajeAdd_System_File.

Si se usa una tabla externa, probablemente, se emplee dentro de uno o más de los siguientes

eventos: Update, Backout, Creating, Deleting, Validate_Save y “Validate_Delete”. Si hacereferencia a una tabla externa en estos eventos, necesita añadir esta tabla a la lista de tablasexternas.

Si usa el comando “Define_Auto_Increment” para definir un campo de Auto-Incremento y la tablaque suministra automáticamente ese Auto-Incremento es una tabla sistema, deberá añadirla a lalista de tablas externas.

Send Add_System_File_ Ordsys.File_Number DD_LOCK_ON_NEW_SAVE_DELETEDefine_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 excepción dela regla que dice que una subclase de Diccionario de Datos debe crearse y usarse para cada tablaen una aplicación.

Puesto que las tablas de sistema contienen sólo un registro que puede ser usado por muchosusuarios, hay un parámetro que optimiza y determina cuándo debe bloquearse la tabla externa.Este parámetro tiene los siguientes valores:

DD_Lock_On_All Se bloquea en todas las grabaciones yborrados.





DD_Lock_On_New_Save_Delete Se bloquea en las nuevas grabaciones yborrados.

DD_Lock_On_Save Se bloquea en todas las grabaciones.

DD_Lock_On_New_Save Se bloquea solamente en las grabaciones denuevos registros.

DD_Lock_On_Delete Se bloquea solamente en borrados.

Para tablas de sistema que soporten números de serie de identificación únicos,DD_Lock_On_New_Save debe ser suficiente; para tablas de contadores secundarios queincrementan y disminuyen, se necesitarían los otros dos modos por lo que DD_Lock_On_All sería

apropiado.Note que esta optimización de bloqueo solamente se aplica a la Base de Datos embebida deDataFlex.





Definir eventos Del Diccionario deDatosParte del proceso de creación de Diccionario de Datos es definir los comportamientospersonalizados de los eventos. Estos eventos permiten que personalice los procesos principalesdel 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 comprobación de errores durante una grabación o unborrado. Si se genera un error, se cancela la grabación o borrado y se deshace cualquiercambio (Roll Back).

• Use los eventos para mantener balances entre tablas relacionadas durante las grabacionesy 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 nuevosregistros. Esto incluye poner valores por defecto para los nuevos registros.

• Use eventos para llevar a cabo procesos especiales de grabación o borrado.

Un evento puede ser usado por múltiples operaciones. Por ejemplo, el evento de “Backout” se

convoca durante una grabación y un borrado. El evento de “Relate_Main_File” puede serconvocado por las grabaciones, borrados, búsquedas y limpiar (Clear).

Algunos eventos se convocan siempre en un estado de bloqueo (Ej. “Update” y “Backout”)mientras que los demás 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





• Validate_Save

Forward sending mensajes de evento

Antes de nada una consideración sobre lo que es “Forward send”. Traducido literalmente delinglés tendríamos 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 eventosllevan a cabo tareas muy importantes y deben ser “Forward send”. A menos que quiera cancelarun comportamiento específico, es aconsejable que “Forward send” siempre sus eventos para

aumentarlos (ampliar sus funcionalidades). Esto crea código robusto que trabajará la primera vezy que continuará trabajando cuando se hagan cambios. Así que mientras podríamos codificar unevento de la siguiente manera:

// IncorrectProcedure Update

Move (Customer.due + order.total) to Customer.dueEnd_Procedure

En vez de esto lo codificaremos con un “Forward send”:

// correctProcedure Update

Forward send UpdateMove (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. Estoseventos se relacionan a campos que usan el “Field_Validate_msg”, “Field_Entry_msg” y “Field_Exit_msg” y se discuten en otros capítulos. En particular, los eventos de validación decampo pueden ser muy útiles.


Definir clases de Diccionario de Datos.





Attach_Main_File

Attach_Main_File lleva a cabo un attach. Se llama durante operaciones de grabación 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 relación entre tablas se mantengan actualizadoscorrectamente.

Note que este Attach solamente se aplica a los “DDOs padre” que están relacionados con esteDDO. Si una “tabla padre” está relacionada con el de la tabla principal (Main Table) DDO pero nohay un padre DDO conectado al DDO, no ocurrirá ningún Attach.

Puede usar este procedimiento parea crear Attaches adicionales, cancelándolos todos o creando

unos propios. La siguiente muestra efectúa un Attach normal a no ser que uno de los Attach decampo se ignora.

Procedure Attach_Main_FileString sTempValMove 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_FileMove 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 relación sucede como parte del “Find”). Attach_Main_File llevaa 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 alBuffer local del DDO (es decir, use la sintaxis de “Move File.Field To Variable”). Para másinformación 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 relación entre tablas.Update es llamado en las modificaciones y altas de registros, mientras que Backout es llamado enlas modificaciones y borrados de registros. Update y Backout se emplean generalmente paraajustar las “tablas padre”. Backout, concretamente, se emplea para eliminar el efecto de unagrabación mientras que la Update se usa para añadir el efecto de una grabación.





Los siguientes Update y Backout en un Diccionario de Datos ajustarían los totales de su padre, latabla vndr.

Procedure UpdateForward Send UpdateMove (Checks.Total.+ Vndr.Total_Paid) to Vndr.Total_Paid

End_Procedure

Procedure BackoutForward Send BackoutMove (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 mayoría de las veces los contenidos de Update y Backout serán el inverso de sí mismos. Si nolo son, deberá revisar su lógica de forma cuidadosa. La mayoría de las veces lo que Updateañada a un total, Backout se encargará de restarlo.

Es posible que Backout y Update puedan ajustar totales de diferentes “tablas padre” durante unaedición. Esto ocurriría si la edición causase que el “Registro padre” cambie. Los DDOs soportanesto.

No asuma que los eventos de Update y Backout solamente se envían una vez durante unagrabación. Si el “Registro padre” de un “Registro hijo” no se cambia, entonces Backout y Updatese llaman una sola vez. En caso de que se cambie el “Registro padre” de un “Registro hijo”,entonces Backout y Update se llaman más de una vez. Por ejemplo: supongamos que nuestratabla de clientes está relacionada con una tabla de zonas geográficas de forma que un clientepertenece a una zona y una zona tiene múltiples clientes. En este caso, nuestra “tabla hijo” es latabla de clientes y la “tabla padre” es la de zonas. Supongamos que en la tabla de zonasllevamos un total de ventas de cada zona que es la suma de las ventas de cada uno de losclientes de esa zona. Si a un cliente le cambiamos de zona (a un “Registro hijo” le cambiamos elpadre) entonces Update y Backout se llaman más de una vez. El proceso de mantener integridadrelacional cuando se cambia el registro padre de un hijo es bastante complejo y ambos eventospueden ser llamados múltiples veces para la misma tabla (para diferentes registros).

Si un cambio en un registro debe ajustar totales en un “Registro padre” y “abuelo” (Ejemplo: elimporte de una línea ajusta los totales de la factura, y esta a su vez el crédito consumido delcliente), es mejor dejar que un Diccionario de Datos actúe sobre su padre(s) inmediato(s) (líneassobre factura y factura sobre cliente).

Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuación por partedel usuario en este evento.

Si declara un error, la transacción se deshará (Roll back). Los errores deben generarse usando elcomando de error. Para más información 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 más información consulte

“Comprendiendo Buffers globales y Buffers locales de DDO”.



Clear_Main_File

Clear_Main_File efectúa un clear sobre la tabla principal del Diccionarios de Datos. Normalmente,querrá realizar un “Forward send” de este mensaje y después cualquier tipo de aumento.

Si desea que este evento limpie (clear) una tabla adicional debe contar el Diccionario de Datossobre esto enviando el mensaje Request_Clear_File:

Procedure Clear_Main_FileForward Send Clear_Main_FileClear AuxFileSend Request_Clear_File AuxFile.File_Number

End_Procedure





Creating (crear)

Creating es llamado como parte del proceso de grabación y se llama cuando se va a grabar unnuevo registro. El comportamiento por defecto de este evento es para manejar “Auto-incrementos” cuando este está definido en la clase con el comando “Define_Auto_Increment”. Poreste motivo debe asegurarse reenviar el evento (Forward send)

Este evento puede usarse para efectuar cualquier procesamiento adicional requerido para unnuevo registro.

Procedure CreatingForward send CreatingSend LogNewRecordData

End_Procedure











Delete_Main_File

El evento de Delete_Main_File efectúa el borrado (delete) del registro. Delete_Main_File estápensado para aumentarse

Normalmente, querrá siempre reenviar (Forward send) este mensaje. Si no se reenvía no se borrael registro.


Si declara un error, la transacción se deshará (Roll back). Los errores deben generarse usando el

comando de error. Para más información consulte “Manejo de error en las transacciones”.




Definir eventos de Diccionario de Datos

Deleting (borrar)Deleting se llama durante el proceso de borrado (delete). Se envía antes del mensaje de Backout.

Procedure DeletingForward send DeletingSend LogDeletedRecord

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 más información 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 después deun Clear. Puede fijar cualquier valor de campo, que se reflejará en los DEOs y será guardado conel registro nuevo.

Puesto que el ajuste de los valores por defecto se codifican en un procedimiento, se pueden crearreglas complicadas.

El ajuste de un valor por defecto no es reconocido como un cambio de datos por el Diccionario deDatos; por lo tanto, el ajuste de los valores por defecto no generará un mensaje de aviso de"pérdida de datos".

Procedure Field_Defaults

Forward Send Field_DefaultsSet 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 también pueden fijarse a la entrada de un DEO creando un método FieldEntry y poniéndolo con la propiedad de Field_Entry_msg. Ese método podría poner el valor pordefecto 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, puestoque se llama después de cada Find, Clear, Save y Delete. Ocurre siempre que CurrentRowIdcambie.





A “On new current Record” se pasan dos parámetros de RowId: el RowId del registro viejo y elRowId del registro nuevo. Observando estos dos parámetros, puede decir si el DDO ha encontradoun 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 envíapara notificar un cambio que va a ocurrir. No puede abortar el cambio.

“On new current Record” se envía cuando el registro en curso está cambiando, con dosexcepciones: si se inicia un DDO y el registro que está establecido es nulo, se llamará “On newcurrent Record” (el registro antiguo = nuevo registro nulo= nulo). Después de una grabación, sellama a “On new current Record” de todos los DDOs que participaron en la grabación, incluso si elregistro no cambió. Si lo necesita podrá comprobar esta condición con “Operation_Mode” y ver sies “Mode_Saving”.

Procedure OnNewCurrentRecord RowId riOldRec RowId riNewRec

Forward Send OnNewCurrentRecord riOldRec riNewRec

// Asumiendo que deseamos atrapar grabaciones de registros nuevosIf (Operation_Mode = Mode_Saving AND ;

IsSameRowId (riOldRec, riNewRec)) Begin:

EndElse....

End_Procedure

Notas especiales

• Este mensaje debe ser reenviado (Forward Send).

• Este evento no existe en la versión 10.1 de Visual DataFlex. En vez de dicha versión seemplea el New_Current_Record. A este evento se le pasan los números de registro(Integers) en lugar de RowIds. El evento de New_Current_Record todavía se convoca perose considera obsoleto. “On new current Record” es su sustituido preferido.



Relate_Main_File

Por defecto, Relate_Main_File no hace nada. Ocurre después de que el “Relate” normal se hayaejecutado. Es un evento que permite ejecutar relaciones personalizadas después de que suregistro 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





registro) o Request_Clear_File (si el registro no se encontró). Request_Relate también ejecutaráun Relate el registro recién encontrado.

Esto es particularmente verdadero si el DDO está actualizando el “DDO padre” del registro que haencontrado. El siguiente código que mostramos a continuación encuentra un “Registro padre” ynotifica al DDO que lo ha encontrado. (Nota: esta es lo que habitualmente se llama “Sofi Find” yno debe confundirse con “Sofi Relate”)

Procedure Relate_Main_FileBoolean bMustFindInteger iFile iStatus

Get Main_File to iFileGet_Attribute DF_FILE_STATUS of iFile to iStatus

Forward Send Relate_Main_File

If (iStatus = DF_FILE_INACTIVE) beginMove True to bMustFind

endElse if (Vndr.Soft_id <>SoftFile.Soft_id) begin

Move True to bMustFindend

If bMustFind Begin / / Solamente relaciona SoftFile si es necesarioC

lear SoftFileMove Vndr.Soft_ID to SoftFile.Soft_IdFind eq.SoftFile.Soft_Id

End

Get_Attribute DF_FILE_STATUS of SoftFile.File_Number to iStatusIf (iStatus<>DF_FILE_INACTIVE) begin

Send Request_Relate SoftFile.File_NumberEndElse begin

S

end Request_Clear_File SoftFile.File_NumberEnd

End_Procedure

Note la optimización de este procedimiento. La búsqueda en SoftFile se lleva a cabo sólo si: elBuffer de SoftFile está vacío o si el registro en el Buffer no es el que queremos (los valoresrelacionados no son los mismos).

Se recomienda optimizar sus búsquedas dentro de Relate_Main_File. Debido a que los DDOs nopueden saber qué está haciendo este procedimiento, no hay, tampoco, ninguna manera deoptimizar estas búsquedas. En el momento en que un DDO piense que la relación personalizadade un registro pudiese ser incorrecta, enviará Relate_Main_File. Esto sucede a menudo. Por eso esimportante que optimice sus búsquedas (un proceso sencillo) para no ralentizar sus operacionesde base de datos.

Preste atención pues Relate_Main_File no siempre encuentra registros que se relacionan con elregistro actual. Cuando se cambia el “registro padre” de un “registro hijo”, Relate_Main_File se

llamará durante el proceso de grabación para encontrar registros relacionados con el “padre





nuevo” y el “padre antiguo”. Debido a esto, CurrentRowId (o el obsoleto Current_Record) no debeusarse en los procedimientos de Relate_Main_File. Dentro de Relate_Main_File debe de hacersereferencia al valor real del Buffer del fichero o el RowId (usar la función de GetRowId) de la tabla.

Se puede usar OnNewCurrentRecord para hacer el seguimiento de cambios en CurrentRowId.





Save_Main_FileSave_Main_File sirve para grabar el fichero principal. Puede usar Save_Main_File para tablasadicionales no relacionadas o para procesar cambios adicionales en su tabla.

Save_Main_File se llama para cada tabla que se graba en una operación del Diccionario de Datos.Este método puede llamarse incluso si no hay ningún cambio para grabar. En tal caso, lagrabación física 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 lafecha y la hora en un campo puede causar que un registro no modificado se grabe, únicamentecambiaremos 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_FileBoolean bChangedInterger iFileGet Main_File to iFileGet_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_StampGet Crnt_Time to Vndr.Time_Stamp

End // now do the normal save behaviorForward Send Save_Main_File

End_Procedure

Normalmente, siempre haremos un Forward Send de este mensaje. Si el mensaje no se envía, lagrabación no tendrá lugar.











Update y Backout

Los eventos de Update y Backout se usan para mantener balances de relación entre tablas.Update es llamado en las modificaciones y altas de registros, mientras que Backout es llamado enlas 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 unagrabación mientras que la Update se usa para añadir el efecto de una grabación.

Los siguientes Update y Backout en un Diccionario de Datos ajustarían los totales de su padre, latabla vndr.

Procedure UpdateForward Send UpdateMove (Checks.Total.+ Vndr.Total_Paid) to Vndr.Total_Paid

End_Procedure

Procedure BackoutForward Send BackoutMove (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 mayoría de las veces los contenidos de Update y Backout serán el inverso de sí mismos. Si nolo son, deberá revisar su lógica de forma cuidadosa. La mayoría de las veces lo que Update

añada a un total, Backout se encargará de restarlo.

Es posible que Backout y Update puedan ajustar totales de diferentes “tablas padre” durante unaedición. Esto ocurriría si la edición causase que el “Registro padre” cambie. Los DDOs soportanesto.

No asuma que los eventos de Update y Backout solamente se envían una vez durante unagrabación. Si el “Registro padre” de un “Registro hijo” no se cambia, entonces Backout y Updatese llaman una sola vez. En caso de que se cambie el “Registro padre” de un “Registro hijo”,entonces Backout y Update se llaman más de una vez. Por ejemplo: supongamos que nuestratabla de clientes está relacionada con una tabla de zonas geográficas de forma que un clientepertenece a una zona y una zona tiene múltiples clientes. En este caso, nuestra “tabla hijo” es latabla 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 losclientes de esa zona. Si a un cliente le cambiamos de zona (a un “Registro hijo” le cambiamos elpadre) entonces Update y Backout se llaman más de una vez. El proceso de mantener integridad

relacional cuando se cambia el registro padre de un hijo es bastante complejo y ambos eventospueden ser llamados múltiples veces para la misma tabla (para diferentes registros).

Si un cambio en un registro debe ajustar totales en un “Registro padre” y “abuelo” (Ejemplo: elimporte de una línea ajusta los totales de la factura, y esta a su vez el crédito consumido delcliente), es mejor dejar que un Diccionario de Datos actúe sobre su padre(s) inmediato(s) (líneassobre factura y factura sobre cliente).







Validate_delete

La función Validate_Delete se llama justo antes de que tenga lugar un borrado. Se bloquean todaslas tablas que participan en el borrado. Si se genera un error o se devuelve un valor distinto decero, se detiene el borrado.

Una operación de borrado eliminará el registro de la tabla principal y todos los registrosrelacionados de las tablas descendientes (hijos, nietos, etc). Esto se hace para evitar registroshuérfanos. Esta comprobación solamente ocurre si Cascade_Delete_State es verdadero y si hayuna relación “padre- hijo” entre tablas y la estructura de DDO es correcta.

El Validate_Delete solamente se envía al DDO de la tabla principal sobre la que se quiere efectuarel borrado. Si se aprueba el Validate_Delete, el registro de la tabla principal y todos sus “registroshijos” serán eliminados.

Si está prohibiendo supresiones en cascada, es esencial que envíe (Forward Send) el mensajeValidate_Delete. La verificación del borrado en cascada sucede como parte de este envío (ForwardSend):

Function Validate_Delete returns IntegerInteger iErrorForward get Validate_Delete to iErrorIf (not (iError)) Begin

If (Customer.status = "A") BeginError 306 “Cannot delete active record”

End





EndFunction_Return iError

End_Function

Todas las tablas de los DDOs participantes se bloquean durante Validate_Delete. Por lo tanto, lafunción debe ser rápida y no debe requerir nunca una introducción de datos por parte del usuario.La excepción 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 hayansido desbloqueadas.

Un error en cualquiera de los eventos de borrado (Validate_Delete, Deleting, Backout,Delete_Main_File, etcétera.) indica un retroceso de la transacción (Transaction Roll Back). Éste esun proceso especial. Cuando esto ocurra el código pendiente de ejecutarse de la función no seprocesará.

Este mensaje se llama siempre en un estado de bloqueo. En este evento no pida ningunaintroducción de datos al usuario.






Validate_Save

Validate_Save se usa como la validación final de un registro antes de grabarlo. Se envía a cadatabla en la estructura de DDO que participará en la grabación. Ocurre cuando la base de datosestá bloqueada y todos los valores de campo han sido actualizados. Puede consultar directamenteel valor de cualquier buffer de fichero.campo y si cualquier valor o combinación de valores soninválidos, puede detener la grabación 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 excepción para

esto es que los attach del buffer del fichero no han ocurrido todavía. Esto quiere decir que unbuffer de una ”tabla hijo” podría no contener la información del padre para poner en elamortiguador de archivo durante el evento Attach_Main_File. El evento Attach_Main_File ocurredespués de Validate_Save.

Todas las tablas de los DDOs participantes se bloquean durante Validate_Save. Por lo tanto, lafunción debe ser rápida y no debe requerir nunca una introducción de datos por parte del usuario.La excepción de esto es el comando de Error. Un error generado durante el Validate_Save serádiferido hasta que las operaciones de grabación hayan retrocedido (Roll Back) y las tablas hayansido desbloqueadas.





Normalmente, un Validate_Save fallido generará un mensaje de error, como en el ejemplo deabajo.

Function Validate_Save returns Integerinteger iErrorIf (Invt.Qtv < 0) Begin

Error DFERR_OPERATOR "Insufficient Inventory on hand'EndForward get Validate_Save to iErrorFunction_Return iError

End_Function

Un error en cualquiera de los eventos de grabación (Validate_Save, Update, Backout,Save_Main_File, etcétera.) indica un retroceso de la transacción (Transaction Roll Back). Éste es

un proceso especial. Cuando esto ocurra el código pendiente de ejecutarse de la función no seprocesará.

Debido a que los buffers para todas las tablas que están participando han sido actualizados, nodeberá buscar (find), limpiar (clear), borrar (delete) o modificar ningún buffer de fichero.

Esto no debe de confundirse con la validación de campo (Field Validation). La validación de campoocurre antes de que la base de datos se bloquee y antes de que los campos sean actualizados enel buffer del fichero. La validación de campo puede usarse para manejar la mayoría de lasvalidaciones. Validate_Save se emplea, solamente, para manejar validaciones especiales quesolamente 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 actuación por parte

del usuario en este evento.











(constraints y filtros)

Una restricción (Constraint) es una limitación sobre los registros de una tabla que van a servisibles para un componente del programa (ej: una vista, un objeto de Web, un informe…). Haydos razones por las que podría querer limitar los registros en un DDO:

• Cuando un DDO se relaciona con otro. Podría querer que el “DDO hijo” solamente mostrase

los registros que se relacionan con el “DDO padre”. Esto se denomina restricciónrelacionada con “Relates-To Constraint”.

• Una vista o un informe puede estar centrado en un subconjunto de registros. Podríaespecificar de qué clientes y de qué regiones se muestra la información. Esto se denomina

“Filtros por restricción” (Filter Constraints).


La restricción a la hora de desarrollar el proceso.

Herencia de las restricciones.

Optimización de la búsqueda de las restricciones.





Restricción relacionada con RelatesTo Constraints

Set Constrain_File To Customer.File_Number

Una relación con restricciones solamente se emplea cuando se quieren mostrar los “registroshijos” relacionados con un DDO de una “tabla padre”. El ejemplo clásico de una restricciónrelacionada lo podemos encontrar en el sistema “Order Entry” (ejemplo estándar de VDF) endonde en una rejilla se muestran los registros detalle (líneas 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 estáticamente en el nivel de objeto de DD. El siguiente ejemplo restringiría todos losregistros de pedido a un registro de cliente:

Object oCustomer_DD Is A Customer_DataDictionaryEnd_Object / / oCustomer_DD

Object oOrderHea_DD Is A OrderHea_DataDictionarySet DDO_Server To oCustomer_DDSet 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 restricción relacionada está activa, las reglas de propagación para Buscar (Find) ylimpiar (Clear) son diferentes. Esto se comenta con detalle en “Propagación de DDO yrestricciones relacionadas”. Se deben cubrir varios requisitos para que las restriccionesrelacionadas funcionen de forma apropiada:

• Una relación debe estar definida entre la “tabla hijo” y la “tabla padre”. Dicha relación debedefinirse dentro de Database Builder. Esto requiere que la ”tabla hijo” defina el campo o loscampos 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á relacionadodeben de formar un índice por sí mismos.

• La “tabla hijo” deberá tener uno o más índices que permitan Búsquedas rápidas por loscampos 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 lapropiedad de DDO_Server en el hijo.

Las reglas 1 y 2 son reglas estándar usadas para definir cualquier relación “padre-hijo” de formacorrecta. La regla 3 hace posible que los DDOs encuentren, rápidamente, registros relacionados.





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 usarotros í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 seránsatisfactorias.

En nuestro ejemplo anterior, esto requeriría:

• La tabla Order contiene un campo (OrderHea.Customer_number) que encaja con un camposimilar en Customer (Customer.Customer_Number).

• La relación 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 esOrderHea.Customer_Number (OrderHea.Customer_Number x OrderHea.Order_Number).

• El Order DDO, oOrderHea_DD debe definir oCustomer_DD como un “DDO padre” y usar elmensaje set DDO_Server.




Las restricciones relacionadas se puede aplicar en múltiples niveles. En el siguiente ejemplo, lospedidos (orders) son restringidas a clientes y los detalles del pedido (Order-Detail) restringidas alpedido.




Object oOrderDtl_DD Is A OrderDtl_DataDictionarySet DDO_Server To oOrderHea_DDSet Constrain_File To OrderHea.File_Number

End_Object / / oOrderDtl_DD

Estas clases de restricciones se usan habitualmente en informes y en entrada de datos tipocabecera-detalle. Por ejemplo, encontraría primero un cliente luego un pedido (que es el hijo delcliente), posteriormente encuentra los detalle del pedido que son “hijos” del pedido.





Los Diccionarios de Datos soportan “Relleno automático” (Auto-Fill) que pueden ser usadosconjuntamente con restricciones relacionadas. Una Búsqueda en un Diccionario de Datos padrerelacionado siempre, notifica este cambio al Diccionario de datos hijo relacionado. Debido a que el

“DDO hijo” debe contener un registro limitado válido, si Auto_Fill_State es verdadero se podráencontrar el primer registro legítimo. Este comportamiento de relleno automático (Auto-Fill) seusa de entrada de datos para rellener las parrillas de detalle (Detail Grids)

Es una buena regla usar solamente las restricciones relacionadas estrictamente necesarias. Estetipo de restricción (constraint) no es necesario ni para las grabaciones (saves) ni para losborrados (deletes). Solamente se utiliza para buscar registros


Restricciones y filtro.





Restricciones de filtro

Las restricciones de filtro representan todas las restricciones no relacionadas y que sirven parafiltrar los registros por cualquier conjunto de restricciones. Las restricciones de filtro se definendentro de un DDOs en el método OnConstrain y son especificadas dentro de este método usandoel comando de Constrain.

Object oCustomer_DD Is A Customer_DataDictionaryProcedure OnConstrain

Constraint Customer.Status Eq "A"End_Procedure

End_Object / / oCustomer_DD

Las restricciones de filtro son aditivas. Si se definen múltiples restricciones dentro de un eventode OnConstrain, se deben cumplir todas las restricciones para encontrar un registro. Lasrestricciones de filtro también se añaden a restricciones relacionadas. En el siguiente ejemplo,solamente se encontrarán las órdenes si: se están relacionado con el cliente en curso, i el tipo deorden es N, y si la empresa de transporte es “FEDEX”:


Object oOrderHea_DD Is A OrderHea_DataDictionarySet DDO_Server To oCustomer_DD

Set Constrain_File To Customer.File_Number

Procedure OnConstrainConstrain OrderHea.Shipper eq "FEDEX"Constrain OrderHea.Type eq “N”

End_ProcedureEnd_Object / / oOrderHea_DD

Las restricciones del “DDO padre” las heredan sus “DDOs hijos”. Puede que este comportamientopor 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 tabladebe tener un valor específico. Tiene el formato general de:





Constrain {filename.fieldname} {mode} {value}

Algunos ejemplos de filtros de campo son:

Constrain OrderHea.Shipper eq "FEDEX"

Get pbLowerDate to dLowerDateConstrain OrderHea.Date gt dLowerDate

Get psStatusConstraint to sStatIf (sStat<> "") Begin

Constrain Customer.Status eq sStatEnd

Los filtros de campo se crean y se evalúan cuando se crea una restricción y no cada vez que seencuentra un registro. Esto tiene ciertas ventajas. Debido a que el motor de restricción sabe quécampo está siendo filtrado y qué tipo de evaluación está siendo aplicada, es capaz de determinarsi la restricción, teniendo en cuenta el índice usado para la búsqueda, puede ser optimizado. Sipuede ser optimizado, la búsqueda del registro mucho más rápida.

El filtro Constrain-As

El filtro Constrain-As se emplea para especificar que el registro se ajuste a unos criterios definidospor una expresión. 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 expresión debe devolver un valor de verdadero o falso. Si es verdadero, el registro es válido ysi no es filtrado.

La restricción de expresión (Expresion Constraint) es la más flexible. Puede escribir cualquierexpresión que desee, de cualquier nivel de complejidad. Generalmente, usará las expresiones decomparación con “And/Or”. También puede llamar a las funciones dentro de la expresión. Sinembargo, debido a su flexibilidad, esto es también el tipo de restricción más lento. La expresiónse evalúa cada vez que se encuentra un registro. Además, debido a que el motor de restricción notiene ni idea de qué está haciendo en realidad la expresión, una restricción de expresión no puede





ser optimizada (no puede saltar fuera de un índice). Por lo tanto puede ser muy lento en tablasgrandes. 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 capacesde optimizar una búsqueda, el motor de restricción usará esas optimizaciones para llevar a caboentrada y salida de índice. Esto puede reducir el número de registros que tienen que serevaluados usando el filtro Constrain-As y pueden dar un rendimiento satisfactorio.


Object oOrderHea_DD Is AOrderHea_DataDictionarySet DDO_Server To oCustomer_DDSet Constrain_File To Customer.File_Number

Procedure OnConstrainConstrain OrderHea.Type eq “N”"Constrain OrderHea (OrderHea.Shipper= "FEDEX" or OrderHea.Shipper=”UPS”)

End_ProcedureEnd_Object / / oOrderHea_DD


Restricciones y filtros.

El proceso de creación de las restricciones (Constraint)

Generalmente, un conjunto de Constraint se crea una vez y se usa muchas veces. Normalmente,el proceso de creación ocurre automáticamente cuando se activa una vista o un informe. Esteproceso de creación es automático y por lo general no necesitará preocuparse por él.

Podría tener restricciones que cambian dependiendo de la introducción de datos u otrascircunstancias. Por ejemplo, podría querer que algunos usuarios llenen la tabla de clientes con supaís y luego restrinjan el DDO a ese país. Asegúrese de que este cambio de restricciones se reflejeen los DDOs. Esta reconstrucción se hace enviando el mensaje Rebuild_Constraints a todos losDDOs que lo requieran.

El método Rebuild_Constraints hace lo siguiente:

• Borra las Restricción que estableció para el DDO que recibió el mensaje

• Envía OnConstrain al DDO que recibe el mensaje y añade todos los comandos Constrain alconjunto de Restricciones.

• Si se pone la propiedad de Constrain_File en el DDO, añade una Restricción Relates-To alconjunto de Restricciones.

• Si los pbInheritConstraints del DDO son verdaderos, repite los pasos del 2 al 4 para todoslos “DDO padre”.





Generalmente, después de cambiar una restricción puede descubrir que su registro en curso nocumple con las Restricciones que acaba de aplicar. Debido a esto, necesitará encontrar un nuevoprimer registro después de reconstruir una restricción.

En el siguiente ejemplo, un DEO envía un mensaje a su DDO para pasar dos parámetros, el nuevovalor de restricción y el índice a utilizar para encontrar un nuevo primer registro:

Object Customer_DD is a Customer_DataDictionaryProperty String psStatusConstraint

Procedure ConstraintByStatus string sStar integer iIndexSet psStatusConstraint to sStatSend Rebuild_ConstraintsSend Find FIRST_RECORD iIndex

End_Procedure

Procedure OnConstrainSting sStatGet psStatusConstraint to sStatIf (sStat<> "") Begin

Constrain Customer.status eq sStatend




Herencia de las restricciones

Normalmente un DDO heredará las restricciones de su “DDO padre”.

Una restricción se forma o se reconstruye cuando el mensaje Rebuild_Constraints se envía a unDDO. Rebuild_Constraints crea una restricción de expresión interna que contiene todas las reglaspara filtrar el DDO. Bajo circunstancias normales Rebuild_Constraints hace lo siguiente:

• Limpia las restricciones en curso para el DDO.• Envía el mensaje Constrain al DDO lo que dispara el evento OnConstrain.

• Ejecuta todos los comandos de Restricción Constrain/Constraint dentro del evento deOnConstrain. Cada restricción (constraint) se añade a la expresión de restricción(constraint) interna del DDO.

• Después de enviar OnConstrain, hay que verificar si la propiedad de Constrain_File esdistinta de cero. Si esto es así se crea una restricción relacionada (Relates-To Constraint).

• Este proceso (pasos del 2 al 4) se repite del DDO a la tabla para cada “DDO padre” y estose repite para cada padre en la estructura de DDO.





Una vez finalizado el DDO contiene una expresión de Restricciones que consiste en todas lasrestricciones (Constraint) definidas en el DDO principal y de todas las restricciones definidas entodos 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 expresión derestricción contra estos registros. Si falla cualquier restricción, incluyendo las “restriccionespadre”, el registro se considera no válido. Por lo tanto, si se encuentra un registro principal y unode sus “registros padre” contiene una restricción no válida, ese registro principal se considera noválido.

La mayor parte de las veces este método funciona. Hay veces que la herencia de las restriccionespuede interferir en el proceso. Considere una entrada de pedidos en el sistema. En el típicosistema, su registro de detalle se relaciona con una cabecera de orden y una “tabla padre” deartículos. Asumiendo que quiere limitar los registros de existencias a artículos que están activos(Ej. Constrain Invt.Status eq "A"), esto es perfectamente válido para nuevos pedidos. Sin

embargo, si carga un pedido antiguo que contiene artículos, esos artículos no saldrían en su listade líneas de pedido, lo que podría ser confuso.

En tal caso, puede ordenar a los DDOs para que no hereden las restricciones configurando lapropiedad de pbInheritConstraints. Cuando esto ocurra, todas sus líneas del pedido se mostrarán(porque la “restricción padre” no se usa). Sin embargo, si tratara de seleccionar un nuevo registrode artículo, la restricción de artículos se cumpliría (porque la restricción una búsqueda deartículos se ejecuta por el DDO de existencias.)

Por ejemplo, considere que una estructura de DDO de pedido contiene una restricción en el DDOde artículos que sirve para filtrar todos los registros bajo cierto precio. Cuando seleccione losregistros de Invt filtrará solamente aquellos que puedan ser escogidos. En el DDO de detalle delpedido (Líneas de pedido), las restricciones no se heredan. Por lo tanto los pedidos se mostrarán

correctamente con todos los registros de detalle incluso si el detalle apunta a un artículo (Invt) noválido (se asume que era válido cuando se creó el pedido).

Object oVendor_DD is a Vendor_DataDictionaryEnd_Object // oVendor_DD

Object oInvt_DD is a Invt_DataDictionarySet DDO_Server to oVendor_DDProcedure OnConstrain

Constrain invt.Unit_price gt 100End_Procedure

End_Object // oInvt_DD





Object oOrderdtl_DD is a Orderdtl_DataDictionary





Set DDO_Server to oOrderhea_DDSet DDO_Server to oInvt_DDSet Constrain_File to Orderhea.File_Number

// Constraints from parent (like Invt) will not be appliedSet pbInheritConstraints to false

End_Object // oOrderdtl_DD

Set Main_DD to oOrderhea_DDSet Server to oOrderhea_DD

Poner restricciones “padre” en un “DDO hijo”

Si decide heredar las restricciones, también puede poner “restricciones padre” dentro de un “DDO

hijo”. Deberá usar el Filtro Constrain-As como filtro para hacerlo. Por ejemplo, su DDO de detalledel pedido podría contener lo siguiente:

Set pbInheritConstraints to FalseProcedure OnConstrain

// La tabla del Constrain DEBE de ser el nombre del DDO de la tabla principal // pero la expresión puede referirse a un DDO padreConstrain OrderDtl AS (Invt.Active="A")

End

Algunos desarrolladores prefieren usar esta técnica porque guarda todas las restricciones para unDDO en un único sitio (Ej. No tiene que buscar en el “DDO padre” para filtros adicionales).



Optimización de búsquedas de restricción

Si el DDO tuviera que recorrer toda la base de datos para cada búsqueda, los usuarios podríanesperar mucho tiempo para localizar un registro o conjunto de registros. El DDO intentaráoptimizar la búsqueda usando el índice que haya indicado y entrando directamente a esta “parte” del índice. Siempre que se ejecute una búsqueda, las restricciones son evaluadas con el índice enuso para ver si se puede hacer cualquier optimización. Este proceso es automático y no tiene queprogramar nada.

Sin embargo, si el índice en curso no puede ayudar en la búsqueda, el DDO podría tener querecorrer toda la tabla. Si la tabla tiene muchos registros, esto podría ser lento. Debería comprobarsiempre que las búsquedas están optimizadas adecuadamente para el índice que está usando (opor lo menos debería saber que las búsquedas no están optimizadas). Las técnicas para probaresto se comentan en “Depurando DDOs”.





La propiedad de ordenación

Set Ordering to 3

Cuando use restricciones y filtros, a menudo solamente será óptimo un índice. Cuando estosuceda, asegúrese de que esté usando ese índice.

Puede forzar el DDO para que use siempre un índice concreto. Haga esto poniendo la propiedadde ordenación del DDOs a este número de índice. Normalmente, el valor de esta propiedad es - 1,lo que permite que use cualquier índice solicitado por el mensaje de búsqueda.

Object oOrderHea_DD is an OrderHea_DataDictionary

End_Object

Object oOrderDtl_DD is an OrderDtl_DataDictionarySet DDO_Server to oOrderHea_DDSet Constrain_File to oOrderHea.File_NumberSet Ordering to 1 // este es el único índece que puede ser optimizado

End_Object



Guía de Diccionario de Datos

Documents

Transcript of Guía de Diccionario de Datos