Beruflich Dokumente
Kultur Dokumente
www.Moose-Software.com www.VisualDataflex.es
Versiones documento
Versin
1.0
Revisado por
Andrea Guimares
Pginas
Versin inicial. Traducido de Data Dictionary Guide de la ayuda de VDF 12.1
Fecha
31/01/2008
www.Moose-Software.com www.VisualDataflex.es
ndice
Introduccin a los Diccionarios de Datos ........................................................................ 9 Usando Diccionarios de Datos mientras se desarrolla una aplicacin ...................................... 9 Usando Diccionarios de Datos cuando se desarrolla una aplicacin ......................................... 9 Trabajando con Diccionarios de Datos .............................................................................. 10 Creando clases de Diccionario de Datos ......................................................................... 10 Construyendo estructuras de Objeto de Diccionario de Datos............................................ 11 Restricciones y filtros .................................................................................................. 11 Usando los objetos de Diccionario de Datos ................................................................... 12 Usando objetos de Diccionario de Datos con las Aplicaciones de Windows .......................... 12 Usando Objetos de Diccionario de Datos con Aplicaciones Web ......................................... 13 Tablas, columnas y filas................................................................................................ 15 Consulte lo siguiente...................................................................................................... 15 ndices ......................................................................................................................... 16 Consulte lo siguiente...................................................................................................... 16 Relaciones .................................................................................................................... 17 Consulte lo siguiente...................................................................................................... 18 Identidad de disco y RowId .......................................................................................... 19 Tipo de datos de RowId .................................................................................................. 20 Funciones globales de RowId .......................................................................................... 21 La interfaz de Diccionario de Datos de RowId .................................................................... 22 Notas especiales ............................................................................................................ 22 Consulte lo siguiente...................................................................................................... 23 Transacciones, Bloqueos y soporte multi-usuario ......................................................... 24 Consulte lo siguiente...................................................................................................... 24 Buffers de fichero y Buffers de campos de DDO ............................................................ 25 Consulte lo siguiente...................................................................................................... 25
www.VisualDataflex.es
Pgina 3 de 92
www.VisualDataflex.es
Pgina 4 de 92
www.VisualDataflex.es
Pgina 5 de 92
www.VisualDataflex.es
Pgina 6 de 92
www.VisualDataflex.es
Pgina 7 de 92
www.VisualDataflex.es
Pgina 8 de 92
Los Diccionarios de Datos se definen como clases. Crear una clase de Diccionario de Datos para cada tabla. Estas clases sern usadas mientras est desarrollando su aplicacin.
Los Diccionarios de Datos facilitan crear aplicaciones slidas, con buena apariencia y fcilmente mantenible.
www.VisualDataflex.es
Todos los cambios de datos pasan por los DDOs. Antes de que se cambien los datos los Diccionarios de Datos los validan para usar las reglas, simples o complejas, que usted ha desarrollado en sus clases de Diccionario de Datos. Los Diccionarios de Datos son una clase tan importante que se ha desarrollado una herramienta visual, Database Builder, para crear y mantener esas clases. Pretendemos que utilice siempre esta herramienta para mantener sus Diccionarios de Datos. Database Builder crea el cdigo fuente para estas clases. En algunos casos este cdigo se genera automticamente seleccionando las opciones apropiadas en el Database Builder mientras que en otros casos usted crear este cdigo usando el editor de cdigo del Database Builder.
www.VisualDataflex.es
Pgina 10 de 92
Las reglas para montar estructuras de DDO son las mismas para todos estos contenedores. Cada objeto de Diccionario de Datos debe ser creado y conectado a la estructura de forma apropiada. Esto es hecho a travs DDOs hijo creando enlaces con los DDOs padre. Cuando se monta apropiadamente, las estructuras de DDO proveen acceso sincronizado a una jerarqua de datos. Segn sea necesario se propagan mensajes entre varios objetos DD entregando de esta forma un comportamiento homogneo y consistente para las operaciones de Buscar, Limpiar, Grabar y Borrar. Adems se validan estas estructuras antes de permitir el cambiar datos. El Studio maneja por usted la creacin de estructuras de DDOs. Para ms informacin sobre estructuras de DDOs vea: Creando estructuras de Objeto de Diccionario de Datos (DDO).
Restricciones y filtros
Una tarea adicional de los DDOs es permitir que se puedan restringir y filtrar los registros dentro de un componente. Se soportan dos tipos de restricciones: Cuando un DDO se relaciona con otro, usted podra querer que el DDO hijo muestre solamente los registros que se relacionan con el registro en curso en el DDO padre. A esto se llama Relates- To- Constraint o Restriccin por Relacin. Una vista o informe puede necesitar solamente de un subconjunto de datos de cada vez. Podra, por ejemplo, especificar clientes y filtrar por una determinada regin o provincia. A estos se les llama Filter Constraints o Restriccin por filtro.
Ambas clases de restricciones (se pueden combinar juntas) se definen dentro de sus estructuras de DDO. Para ms informacin sobre restricciones y filtros vea: Restricciones y Filtros.
www.VisualDataflex.es
Pgina 11 de 92
En una aplicacin de Web, la conexin entre su DDO y DEO (su navegador) es indirecta, o procesada por lotes. Todos los cambios en un DDO son enviados al navegador en formato HTML como un solo evento. Todos los cambios en un DEO (el navegador) son enviados al DDO una sola peticin de lote. Su Web Browser Object (WBO) coordina esta actividad. El mismo DDO es capaz de soportar diferentes interfaces (por ejemplo: controles de ventanas, pginas HTML, servicios Web) y por lo tanto, la habilidad del DDO de comunicarse con estas interfaces variar. Sin embargo, la lgica bsica de DDO y los servicios de validacin estn soportados en todas las plataformas. Por ejemplo, las validaciones de campo son siempre ejecutadas antes de una grabacin. Puede encontrar ms informacin en cmo usar DDOs en: Usando objetos de Diccionario de Datos en sus componentes.
www.VisualDataflex.es
Pgina 12 de 92
Estos objetos estn diseados para contener las estructuras de DDO y los mtodos que se comunican con esos DDOs. Un desarrollador interacta con los DDOs de la misma forma con la que operan con un BPO en una aplicacin windows. Los WBO esperan que la interfaz visual sea provista creando pginas HTML. Esas pginas son creadas (programadas) usando un servidor de pginas activas (ASP). Las pginas ASP hacen las llamadas en los WBO. Dentro del WBO cree los mtodos para hacer lo que sea necesario. A continuacin haga sus mtodos disponibles a su pgina ASP publicando su Interfaz. Adems, los WBO contienen una serie de interfaces que dan acceso a sus Diccionarios de Datos. Esto permite que lleve a cabo todas las funciones bsicas del Diccionario de Datos (por ejemplo: buscar, borrar, grabar, limpiar,) sin tener que escribir cdigo en los WBO. Los WBO proveen soporte de servicio web. Un servicio web puede o no necesitar acceder al Diccionario de Datos. Si lo hacen, se puede aadir una estructura de DDO al servicio de objeto web o Web Service Object (WSO) y crear mtodos que se comuniquen con los DDOs.
www.VisualDataflex.es
Pgina 13 de 92
www.VisualDataflex.es
Pgina 14 de 92
Los mensajes del Diccionario de Datos usan ficheros (files), campos (field) y registros (records) en sus nombres de interfaz. Algunos ejemplos de esto son Main_File, Field_Options, File_Field_Current_Value, y OnNewCurrentRecord. Mientras que la documentacin usar algunos de estos trminos indistintamente, el uso normal de estos ser: La tabla se usa cuando se consultan tablas de la base de datos. Solamente deber ver la palabra file" en los mensajes de interfaz. El campo se usa cuando se consultan las columnas de una tabla y cuando se hace referencia a la entidad en el Diccionario de Datos que define una columna. Un Diccionario de Datos mantiene las estructuras de la informacin sobre la columna como valores, etiquetas, y opciones (Field_Current_Value, Field_Label, Field_Options) de cada tabla. stos sern referencias como campos (fields) dentro del Diccionario de Datos. Los registros (records) se usan para hacer referencia a una fila de datos de una tabla.
Consulte lo siguiente
Diccionario de datos bsico y conceptos de tabla
www.VisualDataflex.es
Pgina 15 de 92
ndices
En el Diccionario de Datos todas las bsquedas de informacin se producen usando ndices. Los ndices se utilizan para encontrar rpidamente registros individuales y para buscar en una tabla (hacia delante o hacia atrs) en un orden especfico. Para ser usadas adecuadamente por los Diccionarios de Datos, cada anotacin en los ndices debe ser nica. En otras palabras, los segmentos usados para crear un ndice no deben admitir duplicados (deben poder identificar un registro). Generalmente la singularidad est asegurada si se aade el campo de clave primaria como el ltimo segmento(s) del ndice. Los ndices se definen dentro del Database Builder con un nmero de ndice. Ese nmero se usa en los Diccionarios de Datos y en el cdigo de sus programas para determinar qu ndice debera usarse.
Consulte lo siguiente
Diccionario de datos bsico y conceptos de tabla
www.VisualDataflex.es
Pgina 16 de 92
Relaciones
Las relaciones sirven para "normalizar" sus datos. Algunos de los objetivos de la normalizacin son: 1. La eliminacin de grupos repetitivos - Haga una tabla de consulta (lookup list) distinta para cada juego de atributos relacionados, y de una clave primaria a cada tabla. Por ejemplo, podra estar grabando contactos en sus clientes. No deber guardar los contactos en la tabla de clientes; sin embargo pondr la informacin de contacto en una tabla distinta y relacione cada registro con la clave primaria de su tabla de clientes. 2. Eliminar los datos redundantes- Si un atributo depende solamente de parte de una clave multisegmento, retrelo a una tabla distinta. Supongamos que cada contacto que tenga con un cliente es categorizado (llamada telefnica, correo, visita personal, etctera). Deber guardar el tipo de contacto en una tabla distinta y relacionar los contactos con los tipos de contactos. 3. Eliminar columnas que no sean dependientes de una clave- Si los atributos no contribuyen a una descripcin de la clave, retrelos a una tabla distinta. Por ejemplo, suponga que est almacenando el nombre del cliente, direccin de Empresa y nmero de telfono de Empresa. Estos atributos describen el lugar del trabajo del cliente, no el cliente, as que deber crear una tabla de Empresa y quitar la informacin de Empresa de la tabla del cliente pasndola a esta nueva tabla relacionando la tabla de clientes con esta otra. stas son las primeras tres formas de la normalizacin de datos y son probablemente las tres que ms desee aplicar comnmente en su base de datos. Las relaciones se representan en Visual DataFlex usando el modelo de clave fornea (foreing key) y clave primaria (primary key): 1. Una relacin debe ser definida de tabla hijo a tabla padre. Una tabla hijo define a un campo o conjunto de campos que se corresponden con un conjunto de datos en el padre. El tamao y el tipo de datos de campo en el padre y el hijo deben ser los mismos. Esta relacin se define usando el Database Builder. 2. Los valores de los campos relacionados en el padre (Ej. A, B y C) deben ser nicos y soportados por un ndice cuyos segmentos son los mismos que los campos relacionados (A, B, C de arriba). El campo relacionado en la tabla padre es casi siempre su clave primaria y se refiere en el Diccionario de Datos como el campo clave (key field). 3. La tabla hijo generalmente tiene uno o ms ndices que permiten la bsqueda rpida por los campos relacionados. Esto quiere decir que los primeros segmentos en este hijo debe consistir de los campos a los que se relacionan. Los Diccionarios de Datos utilizan las relaciones en cuatro maneras: 1. Relacionar: cuando un Diccionario de Datos encuentra un registro, todos los DDOs padre encontrarn automticamente todos los registros relacionados. El DDO padre de esos DDOs buscar y encontrar los registros relacionados en la estructura superior (lo que se dice normalmente hacia arriba). De esta forma el buscar/relacionar encuentra una estructura entera de registros relacionados.
www.VisualDataflex.es
Pgina 17 de 92
Consulte lo siguiente
Diccionario de datos bsico y conceptos de tabla
www.VisualDataflex.es
Pgina 18 de 92
// Low level commands using recnum Integer iTempRec Move Customer.Recnum to iTempRec Clear Customer : Move iTempRecnum to Customer.Recnum Find EQ Customer by recnum // Data Dictionary methods using recnum Integer iTempRec Integer iFile Get Current_Record of hoDDO to iTempRec Send Clear to hoDDO : Get Main_File of hoDDO to iFile Send Find_by_Recnum of hoDDO iFile iTempRec Si su base de datos usa una clave primaria como nico identificador, podr usar otros comandos y mensajes de Diccionario de Datos para identificar y buscar registros.
// low level commands using primary key String sTempId Move Customer.Customer_Id to sTempId Clear Customer : Move sTempId to Customer.Customer_Id
www.VisualDataflex.es
// Low level commands using RowId RowId riTempId Boolean bFound Move (GetRowId(Customer.File_Number)) to riTempId Clear Customer : Move (FindByRowId(Customer.File_Number,riTempId)) to bFound // Data Dictionary methods using RowId RowId riTempId Get CurrentRowId of hoDDO to riTempId Send Clear to hoDDO : Send FindByRowId of hoDDO riTempId Usando esta sintaxis de RowId, tendr una sintaxis nica que puede usar en cualquier tabla de cualquier base de datos. Una vez definido, simplemente programe usando RowId.
www.VisualDataflex.es
Pgina 20 de 92
Move (FindByRowId(iFile,riRowId)) to bFound Move (GetRowId(iFile)) to riRowId Move (NullRowId()) to riRowId Move (IsNullRowId(riRowId)) to bIsNull Move (IsSameRowId(riRowId1,riRowId2)) to bIsSame Move (SerializeRowId(riRowId)) to sSerializedRowId Move (DeSerializeRowId(sSerializedRowId)) to riRowId
Estas funciones permiten que lleve a cabo cualquier evaluacin de RowId que se necesite en un nivel bajo: Function RunOrderDtlReport RowId riHdrId Returns RowId RowId riEnd Boolean bFound Move (FindByRowId(OrderHea.File_Number,riHdrId)to bFound If bFound Begin Set priStartRowId To (NullRowId()) Get DoRunReport To iStat Get priEndRowId To riEnd End Else Begin Move (NullRowId()) To riEnd end Function_Return riEnd End_Function
www.VisualDataflex.es
Pgina 21 de 92
Send FindByRowId of hoDDO iFile riRowId Send ReadByRowId of hoDDO iFile riRowId Get CurrentRowId of hoDDO to riRowId Get HasRecord of hoDDO to riRowId
Estos mtodos, junto con las funciones globales de RowId se pueden usar para manejar cualquier tipo de programacin de RowId usando Diccionario de Datos. Function RunOrderDtlReport RowId riHdrId Returns RowId RowId riEnd Boolean bFound Integer iMain Get Main_File of oOrderHea_DD to iMain Send FindByRowId of oOrderHea_DD iMain riHdrId Get HasRecord of oOrderHea_DD to bFound If bFound Begin Set priStartRowId To (NullRowId()) Get DoRunReport To iStat Get CurrentRowId of oOrderDtl_DD To riEnd End Else Begin Move (NullRowId()) To riEnd end Function_Return riEnd End_Function
Notas especiales
No confunda RowId con clave primaria. Si su base de datos soporta campos de recnum, sus tablas probablemente todava tendrn una clave primaria (Ej. tendrn un campo o conjunto de campos que estn indexados de forma nica) que ser identificado en su clase de Diccionario de Datos activando la propiedad Key_Field_State. Ese es el campo que usar en las relaciones. Mientras esos campos, en teora, podran usarse para identificar RowId, no lo harn porque la definicin interna de Recnum de la base de datos provee la manera ms rpida de encontrar un registro. Le interesa siempre usar el mtodo ms rpido para encontrar los registros. Deber usar siempre aquel mtodo que su base de datos o controlador provea que es ms rpido.
www.VisualDataflex.es
Pgina 22 de 92
Consulte lo siguiente
Diccionario de Datos bsico y conceptos de tablas
www.VisualDataflex.es
Pgina 23 de 92
Consulte lo siguiente
Diccionario de Datos Bsico y Conceptos de Tabla
www.VisualDataflex.es
Pgina 24 de 92
Consulte lo siguiente
Diccionario de Datos bsico y conceptos de tablas
www.VisualDataflex.es
Pgina 25 de 92
// use of the field keyword Get Field_Current_Value of oCustomer_DD Field Customer.Name to sName Set Field_Changed_Value of oCustomer_DD Field Customer.Name to sName // use of the File_Field keyword Get File_Field_Current_Value of oOrder_DD File_Field SalesP.Name to sName Set File_Field_Changed_Value of oOrder_DD File_Field SalesP.Name to sName Los comandos de tipo Field son usados con los mensajes de tipo Field. Use estos cuando el objeto de Diccionario de Datos (DDO) que recibe el mensaje posea el campo. En el ejemplo anterior, Customer.Name es definido dentro del DDO de oCustomer_DD. Los comandos de tipo File_Field son usados con los mensajes de tipo File_Field. Use estos cuando el objeto de Diccionario de Datos que recibe el mensaje quizs no posea el campo que puede pertenecer al DDO o a uno de sus DDOs padre. En el ejemplo anterior, SalesP.Name est definido dentro del DDO oOrder_DD pero el campo pertenece al DDO padre, oSales_DD. File_Field se usa en estas situaciones mientras que el DDO desviar el mensaje hacia el DDO apropiado. Para comprender con detalle los comandos tipo File_Field y Field consulten en Entiendo los comandos de tipo File_Field y Field.
Consulte lo siguiente
Diccionario de Datos bsico y conceptos de tablas
www.VisualDataflex.es
Pgina 26 de 92
Normalmente, cuando use Diccionarios de Datos no necesitar usar estos mandatos. En algunos de los eventos de Diccionario de Datos puede usarlos para manejar las operaciones personalizadas de bajo nivel. Por ejemplo, podra desear llevar a cabo alguno tipo de bsqueda personalizada en el proceso de Relate_Main_File. En estos casos podra usar estos comandos. Adems, podra usar estos comandos y limitar el uso de un Diccionario de Datos. Es ms probable hacer esto cuando se busquen registros. Usar un comando directo para grabar o borrar registros no es recomendable porque estara evitando todas las reglas de validacin que los DDOs hacen cumplir.
Consulte lo siguiente
Diccionario de datos bsico y conceptos de tabla
www.VisualDataflex.es
Pgina 27 de 92
En vez de crear una capa adicional de la interfaz de DDO para acceder a estos valores, es mejor que acceda a esta informacin directamente dentro de un DDO o de un componente usando el comando de Get_Attribute. La mayora de estos atributos son de bajo nivel por lo que rara vez necesitar acceder a ellos. Si no puede encontrar un mensaje de DDO que devuelva la informacin que necesita, verifique los atributos de API. Dentro de una aplicacin, lo ms solicitado, aparte de los atributos de API, son la longitud de campo y el tipo de datos del campo. El comando Set_Attribute tambin puede usarse para cambiar atributos de la base de datos. Rara vez necesitara hacer esto dentro de una aplicacin.
Consulte lo Siguiente
Diccionario de datos bsico y conceptos de tabla
www.VisualDataflex.es
Pgina 28 de 92
www.VisualDataflex.es
Pgina 29 de 92
Todos estos ajustes se crean y se mantienen actualizados usando Database Builder. El listado de abajo es un Define_Fields de muestra que fue creado usando Database Builder: Procedure Define_Fields Forward Send Define_Fields //DDB-Generated-Code-Location //DDB-DefineFieldStart Set Main_File To Orderhea.File_Number
Set Foreign_Field_Options DD_KEYFIELD To DD_FINDREQ Set Foreign_Field_Options DD_INDEXFIELD To DD_NOPUT Set Foreign_Field_Options DD_DEFAULT To DD_DISPLAYONLY // Child (Client) file structure................ Send Add_Client_File Orderdtl.File_Number // Parent (Server) file structure............... Send Add_Server_File Customer.File_Number Send Add_Server_File Salesp.File_Number // External (System) file structure............. Send Add_System_File Ordsys.File_Number DD_LOCK_ON_NEW_SAVE_DELETE Define_Auto_Increment Ordsys.Order_Number To Orderhea.Order_Number // Field-based properties....................... // Orderhea.Order_Number Set Field_Options Field Orderhea.Order_Number To DD_AUTOFIND
www.VisualDataflex.es
Pgina 30 de 92
Field Orderhea.Ship_Via To "dbComboForm" Field Orderhea.Ship_Via To (Ship_Table(Self)) Field Orderhea.Ship_Via To "Shipping method"
// Orderhea.Ordered_By //DDB/ Comment_Short Field Orderhea.Ordered_By To "This is just a suggested list. No parent files support this" Set Status_Help Field Orderhea.Ordered_By To "Order placed by" // Orderhea.Salesperson_Id Set Field_Label_Long Field Orderhea.Salesperson_Id To "Sales Person Id" Set Field_Label_Short Field Orderhea.Salesperson_Id To "Sales ID" Set Status_Help Field Orderhea.Salesperson_Id To "Sales Person who initiated the order" // Orderhea.Order_Total //DDB/ Comment_Short Field Orderhea.Order_Total To "Maintained by the Orderdtl DD" Set Field_Mask_Type Field Orderhea.Order_Total To MASK_CURRENCY_WINDOW Set Field_Options Field Orderhea.Order_Total To DD_DISPLAYONLY // Orderhea.Last_Detail_Num //DDB/ Comment_Short Field Orderhea.Last_Detail_Num To "This is the " //DDB-DefineFieldEnd End_Procedure // Define_Fields El constructor de Define_Fields puede usarse solamente en clases. No puede crear o aumentar Define_Fields dentro de un DDO.
www.VisualDataflex.es
Pgina 31 de 92
www.VisualDataflex.es
Pgina 32 de 92
Class cTheMostSimpleCustomer_DD is a DataDictionary Procedure Define_Fields Forward Send Define_Fields set Main_File to MyTable.File_Number End_Procedure End_Class
Consulte lo siguiente
Definir los atributos de tabla de Diccionario de Datos.
www.VisualDataflex.es
Pgina 33 de 92
Key_Field_State
Set Key_Field_State Field Customer.Id to true Key_Field_State marca un campo como el campo principal para la tabla. Una ventaja de fijar esta alternativa puede ser prevenir los cambios en los datos guardados en el campo, es decir, no se pueden modificar los datos de un campo clave. Esto se conoce como proteccin de campo clave (Key Field Protection). La proteccin de campo de la clave primaria evita que los datos de los campos que componen la clave primaria se modifiquen una vez que el registro sea creado (por ejemplo: si la clave primaria de una tabla de clientes es cliente.cdigo no interesara modificar el cdigo una vez que ya se haya creado el cliente). Generalmente pondra esta opcin sobre campos de claves primarias como el campo de nmero de pedido en una tabla de cabecera de pedido o el campo de identificacin del cliente en la tabla de clientes. Esto proporciona proteccin de orfandad impidiendo que sean modificados los campos de identificacin usados en las relaciones padre/hijo. Si su clave primaria consta de varios campos, todos los campos de la clave deben ser marcados como campos clave. Los campos clave solamente estn protegidos en una tabla si la propiedad de Protect_Key_State tambin est activada en el Diccionario de Datos.
Protect_key_State
Set Protect_Key_State to true Protect_Key_State determina si los campos que componen una clave primaria deben ser protegidos despus de que hayan sido grabados por primera vez en un nuevo registro. Cuando estn marcados a verdadero (true), un campo identificado como parte de una clave no puede ser editado despus de que haya sido grabado. Esto asegura que los registros hijo que se relacionan con un registro padre a travs de una clave primaria, no se puedan por cualquier casualidad dejar hurfano. Los campos que componen una clave primaria son identificados usando la propiedad de campo Key_Field_State.
Consulte lo siguiente
Definir los atributos de tabla de Diccionario de Datos.
www.VisualDataflex.es
Pgina 34 de 92
No_Delete_State
Set No_Delete_State to True No_Delete_State desactiva borrados directos de los registros. Esto quiere decir que el mensaje que Request_Delete enviado a este DDO generar un error y no llevar a cabo ninguna accin. Este mensaje no afecta a borrados de los registros que son parte de un borrado en cascada.
Cascade_Delete_State
Set_ Cascade_Delete_State to True Cascade_Delete_State especifica cmo afecta una orden de borrados (delete) a los registros relacionados de una tabla hijo, cuando el borrado se enva al padre. Si Cascade_Delete_State es verdadero, entonces los registros de la tabla hijo y todos los registros descendientes sern eliminados. Si la propiedad est a falso, se permitir el borrado cuando no exista ningn registro hijo. Ambos mtodos aseguran que ese registro hijo nunca se deje hurfano.
www.VisualDataflex.es
Pgina 35 de 92
Consulte lo siguiente
Definir los atributos de tabla de Diccionario de Datos.
www.VisualDataflex.es
Pgina 36 de 92
www.VisualDataflex.es
Pgina 37 de 92
Por ejemplo, podra definir que un campo fuera Not-Put, Auto-Find y CAPSLOCK fijando las siguientes propiedades:
Field_Options field Customer.Id to DD_NoPut Set Field_Options field Customer.Id to DD_AutoFind Set Field_Options field Customer.Id to DD_CapsLock Debido a que a menudo hay opciones mltiples que deben ser aplicadas al mismo campo, se le permite combinar mltiples opciones en una sola lnea de la siguiente manera:
Set Field_Options field Customer.Id to DD_NoPut DD_AutoFind DD_CapsLock Field_Options puede ser fijado y modificado a nivel de Objeto de DD (DDO). Cuando lo use a nivel de objeto, no podr usar el mensaje de Field_Options. En vez de esto podr usar Field_Option (fjese que va en singular), Field_Option_Clear y Field_Option_Toggle. Para ms informacin vea Cambiar propiedades de campo dentro de DDO.
Set Field_Option field Customer.State to DD_Retain Set Field_Option_Clear field Customer.State to DD_Retain Set Field_Option_Toggle field Customer.State to DD_Retain
www.VisualDataflex.es
Pgina 38 de 92
UPPERCASE (DD_CapsLock)
Set Field_Options field Customer.Id to DD_CapsLock
www.VisualDataflex.es
Pgina 39 de 92
Set Field_Options field Customer.Id to DD_ForcePut DD_ForcePut fuerza a los contenidos de los Forms de entrada de datos a que pongan en el buffer de registro de la tabla antes de una grabacin incluso si no se ha hecho ningn cambio. Normalmente los contenidos de los Forms de entrada de datos, solo se ponen en El buffer si han sido cambiados en relacin a lo que fue mostrado originalmente desde el disco.
No-Enter (DD_NoEnter)
Set Field_Options field Customer.Id to DD_NoEnter DD_NoEnter evita la introduccin de datos a travs de cualquier Form asociado con el campo. Nota especial: La opcin Skip-Found (DD_SkipFound) tiene un efecto similar, excepto que permite que el cursor vaya a ese elemento si no se encontr ningn registro. No-Enter pasa por alto el Form sin considerar si se encuentra un registro. La alternativa DD_DisplayOnly es una combinacin de DD_NoEnter y DD_NoPut. Aunque los datos no puedan ser introducidos desde el teclado a un Form controlado por No-Enter. Estos pueden ser movidos al Form bajo el control del programa. Esos sern pasados al buffer y grabados, cosa que no se hace con las opciones de campo Display_Only y No_Put.
No-Put (DD_NoPut)
Set Field_Options field Customer.Id to DD_NoPut DD_NoPut no permite que los datos se pasen de los Forms de entrada al buffer de registro del campo, incluso si se han introducido datos nuevos va teclado. No-Put es til para permitir que se introduzcan datos en un Form donde no desee permitir que se modifique el campo. Use la opcin No-Put cuando quiera impedir que los usuarios cambien los datos. La alternativa DD_DisplayOnly es una combinacin de DD_NoEnter y DD_NoPut.
www.VisualDataflex.es
Pgina 40 de 92
// This is the same as DD_DisplayOnly Set Field_Options field Customer.Id to DD_NoEnter DD_NoPut
Retain(DD_Retain)
Set Field_Options field Customer.Id to DD_Retain DD_Retain (mantener) evita que los Forms de entrada de datos asociados al campo se limpien (vacen) cuando el usuario inicia una operacin que normalmente limpiara todos los Forms de una vista. Si el usuario inicia la operacin clear-all, entonces no se conservar absolutamente ningn dato. Es algo que habitualmente no se puede aplicar a todos los objetos en todas las vistas que usen una clase DD en concreto. En vez de eso, la opcin de mantener (Retain) se debera basar en los requisitos especficos de entrada de datos de una vista. Por lo tanto se espera que Retain sea aplicado en nivel de objeto de DD y no como parte de la definicin de clase.
Retain-All (DD_RetainAll)
Set Field_Options field Customer.Id to DD_RetainAll DD_RetainAll impide que los Forms de entrada de datos asociados con el campo se limpien (vacen). Aunque los usuarios no puedan limpiar el Form, la entrada de datos s podra hacerlo manualmente borrando carcter a carcter presionando la tecla Limpiar. Es algo que habitualmente no se puede aplicar a todos los objetos en todas las vistas que usen una clase DD en concreto. En vez de eso, la opcin de mantener (Retain) se debera basar en los requisitos especficos de entrada de datos de una vista. Por lo tanto se espera que Retain sea aplicado en nivel de objeto de DD y no como parte de la definicin de clase.
www.VisualDataflex.es
Pgina 41 de 92
Zero-Suppress (DD_Zero_Suppress)
Set Field_Options field Customer.Id to DD_Zero_Suppress DD_Zero_Suppress limpia el Form de entrada de datos del campo si este es numrico con valor cero (0). DD_Zero_Suppress parecer no funcionar en donde haya un valor absoluto pequeo en un Form. Por ejemplo, si un Form especifica valores enteros de visualizacin y un valor de campo inferior a 1 (por ejemplo 0,5) se mostrar cero en el Form. Solamente un valor que sea realmente cero (0) ser mostrado como espacios en blanco.
Require (DD_Required)
Set Field_Options field Customer.Id to DD_Required DD_Required se asegura de que se introduzcan datos en un campo. Cualquier carcter o caracteres que se introduzcan en el Form de entrada de datos permitirn que el cursor se mueva al siguiente Form. Este requisito se aplicar tambin durante la validacin de grabacin.
Find-Required (DD_FindReq)
Set Field_Options field Customer.Id to DD_FindReq DD_FindReq impide que el cursor se vaya al siguiente Form de entrada de datos hasta que se encuentre un registro vlido del campo asociado al Form. Una bsqueda fallida causa un Error 90 (por favor introduzca un registro vlido). Find required no tiene ningn efecto si un registro activo para la tabla ya est en la vista.
www.VisualDataflex.es
Pgina 42 de 92
Set Field_Option_Clear Field Customer.Name to DD_Retain Field_Option_Toggle (and File_Field_Option_Toggle) alternan las opciones de campo pasadas por este mensaje
Set Field_Option_Toggle Field Customer.Name to DD_Retain Estos mensajes rara vez son usados en clases de Diccionario de Datos. Cuando sean usados se emplearn en los DDOs para controlar dinmicamente una vista de entrada de datos. Vea Cambiar propiedades de campo con DDOs para ms informacin.
Consulte lo siguiente
Definir atributos de campo de Diccionario de Datos.
www.VisualDataflex.es
Pgina 43 de 92
Adems, para cualquier campo puede definir un mtodo personalizado de validacin (Field Validation Method). Este mtodo, una funcin, se asigna a un campo fijando el mensaje de validacin de campo (Field Validation Message). Esta funcin se llama durante la validacin. Si se detecta un error, la funcin debe generar uno y devolver un valor distinto de cero. Esta funcin permite que cree cualquier tipo de regla de validacin que necesite. La validacin de campo ocurre durante la navegacin hacia delante (Forward Navigations) y las paradas. Usar validaciones de campo asegura que los datos que se estn grabando en su base de datos son vlidos.
Rangos (Range)
Set Field_Value_Range.field Customer.discount to 0 60 El mtodo de Field_Value_Range permite definir un valor mnimo y mximo para el campo. El campo y sus rangos deben ser numricos o fechas. El valor Desde debe ser inferior al del Hasta. La validacin se lleva a cabo despus de que el usuario haya introducido los datos en el Form de entrada de datos del campo. Si falla la validacin, entonces el usuario no podr dejar el Form. (El usuario todava puede salir del Form haciendo clic con el ratn en otro lugar de la pantalla).
www.VisualDataflex.es
Pgina 44 de 92
Verificacin (Check)
Set Field_Value_Check field Customer.region to " N|S|E|W" El mensaje de Field_Value_Check se emplea cuando la lista de valores vlidos est limitada a un juego esttico y pequeo de valores. Estas muestras estn identificadas en una cadena de comprobacin (Check String). Esto consta de una lista de valores vlidos separados por el Smbolo "|". Por ejemplo, para posibles valores vlidos A, B, C, se usara la cadena A|B|C, mientras que para valores vlidos Po, Ou, Lu se representara con la cadena Po|Ou|Lu La validacin se lleva a cabo despus de que el usuario haya introducido los datos en el Form de entrada de datos del campo. Si falla la validacin, entonces el usuario no podr dejar el Form. (El usuario todava puede salir del Form haciendo clic con el ratn en otro lugar de la pantalla). Adems de usarse para validar, estos valores tambin pueden usarse con elementos de entrada Combo-Box. Si se asigna un dbComboForm a un campo que usa valores de verificacin (Check), cada valor del String de verificacin ser cargado en la lista de combo (Combo-List).
Set Field_Value_Check field Customer.state to "Po|Ou|Lu|SA" Quizs el ejemplo de Customer.state no sea probablemente una buena muestra de de este mtodo de validacin. Aadir nuevas provincias a esta lista requiere cambios de programa, y el String puede ponerse demasiado grande para ser prctico. En ese caso, querr usar una tabla de validacin (Validation Table). Cuando hay un error de validacin, el nmero de error y el texto especificado para el campo en la propiedad de Field_Error se usan para informar del error. Si no se define ningn texto, se informa con el texto de error estndar. La validacin de verificacin (Check) es limitada. Una manera ms flexible y reutilizable de especificar una lista de entradas vlidas es usar una Tabla de Validacin.
www.VisualDataflex.es
Pgina 45 de 92
Cuando ocurre un error de validacin, el nmero de error y el texto especfico para el campo en la propiedad de Field_Error se emplean para informar sobre un error. Si no se define ningn texto, se informar con un texto estndar. El uso de tablas de validacin da una flexibilidad tremenda. Ms adelante se hablar con detalle de cmo usar tablas de validacin. Por ahora abordaremos el tema de las clases primarias de Tablas de Validacin:
Object oStatusTable is a ValidationTable Procedure Fill_List Send add_table_value "O" Send add_table_value "C" Send add_table_value D End_Procedure End_Object
www.VisualDataflex.es
Pgina 46 de 92
Object oStatusTable is a CodeValidationTable Set Type_Value to "Status" End_Object Cualquiera de las tablas de validacin de arriba puede ser conectada a un campo con el mensaje de Field_Value_Table en un Diccionario de Datos.
Pgina 47 de 92
Function ValidateCredit Integer iField Number nValue ; Returns Boolean Boolean bErr String sCustRating // get the customer rating for this customer from DD buffer Get Field_Current_Value field Customer.Rating to sCustRating // If customer Rating is A1 their limit is 5000 If (sCustRating = "A1" and nValue> 5000) Begin Error DFERR_OPERATOR "Credit limit may not exceed $5000" Move True To bErr End Function_Return bErr End_Function
Para usar esta funcin en el campo Credit_Limit de una tabla, debe establecer el mtodo de validacin (Field_Validate_msg) al Handle Name de la funcin. El Handle Name de una funcin es el nombre de la funcin con el prefijo Get (por ejemplo: Get_ValidateCredit). Set Field_Validate_msg field Customer. Credit_Limit to get_ValidateCredit El prototipo de declaracin para un mtodo de validacin tiene la siguiente forma. Function_function_name integer iField type CurrentValue returns integer Dnde: Function_name es el nombre de la funcin de validacin; iField es el nmero de campo del campo que envi function_name. El nmero de campo puede ser usado para recuperar cualquier informacin sobre el campo y TypeCurrentValue es el tipo de datos y el valor actual del campo que envi function_name.
Esto le permite escribir funciones de validacin de mtodos generalizados que pueden ser usados por otros campos y tablas.
www.VisualDataflex.es
Pgina 48 de 92
Consulte lo siguiente
Definir los atributos de campo de Diccionario de Datos.
Las mscaras no son la validacin y no deben ser usadas como una tcnica de validacin. Las mscaras se definen poniendo dos propiedades de campo: Field_Mask_Type y Field_Mask. Las mscaras se comentan con ms detalle en Mscaras en las aplicaciones de Windows.
Etiquetas (Labels)
Set Field_Label_Long Field Orderhea.Terms To "Terms of Payment" Set Field_Label_Short Field Orderhea. Terms To "Terms" Se pueden asignar etiquetas largas y cortas a cada campo. Las etiquetas de campo largas y cortas se definen usando las propiedades de Field_Label_Long y Field_Label_Short. Cuando obtenga el valor de una etiqueta deber usar la funcin Field_Label.
www.VisualDataflex.es
Pgina 49 de 92
Se aplica la misma lgica cuando el Studio o los asistentes (Wizards) se usan para disear vistas e informes. El Studio usar la etiqueta larga al crear controles de tipo Form (por ejemplo., DbForm, dbComboForm). Sin embargo usa las etiquetas cortas al crear controles de estilo de columna (por ejemplo., DbGrid).
Consulte lo siguiente
Definir los atributos de campo de Diccionario de Datos.
www.VisualDataflex.es
Pgina 50 de 92
Mtodo de entrada
Set Field_Entry msg Field Customer.State To EntryCustomerState Field_Entry_msg permite que especifique el nombre de un mtodo que se ejecuta siempre que el cursor se mueve un Form de entrada de datos conectado al campo. El mtodo de entrada, un procedimiento, puede ser programado para llevar a cabo cualquier accin. Podr usarlo para mostrar informacin especial o valores por defecto cada vez que el cursor vaya al campo. En Visual DataFlex, los procedimientos pueden devolver un valor entero. En el caso de un mtodo de entrada (Entry method), si se devuelve un valor distinto de cero, se aborta la entrada del cursor al Form. Usar los mtodos de entrada para controlar la navegacin es muy desaconsejable. El mtodo de entrada debe ser un procedimiento de la clase de Diccionario de Datos de la tabla. Por ejemplo si tiene el siguiente procedimiento:
Procedure EntryOrderDate Interger iField Date dDate // Add a default date if the fields is blank Boolean bChanged Get Field_Changed_State iField to bChanged If (not (bChanged) AND dDate = 0) Begin SysDate dDate Set Field_Default_Value iField to dDate End End_Procedure Para usar este procedimiento en un campo fecha de una tabla, pondra el mtodo de entrada de campo a EntryOrderDate. Estara asignando el manejador de mtodo msg_EntryOrderDate pero si se omite el prefijo "msg" este ser proporcionado automticamente.
www.VisualDataflex.es
Pgina 51 de 92
Set Field_Entry_msg Field Orderhea.Order_Date To EntryOrderDate El prototipo de declaracin para un mtodo de entrada tiene el siguiente formato general. procedure procedureName integer iField type currentValue Dnde: procedureName es el nombre del procedimiento; iField es el nmero de campo del campo que envi procedureName. El nmero de campo puede usarse para obtener cualquier informacin sobre el campo. Type y currentValue son el tipo y el valor actual del campo que envi procedureName.
Los parmetros que se pasan al mtodo de entrada permiten que escriba procedimientos generalizados que pueden ser reutilizados en otros campos y tablas.
Mtodo de salida
Set Field_Exit_msg Field Customer.Zip To ExitAdjustZip Field_Exit_msg permite que especifique el nombre de un mtodo que se ejecute siempre que el cursor se va de un Form de entrada de datos conectado al campo. El mtodo de salida, un procedimiento, puede ser programado para llevar a cabo cualquier accin. Por ejemplo, podra usarlo para ajustar valores de algunos datos calculados que estn en funcin del valor del campo introducido. En Visual DataFlex, los procedimientos pueden devolver un valor entero. En el caso de un mtodo de salida, si se devuelve un valor distinto de cero se aborta la accin de salir del Form de entrada de datos. No se recomienda utilizar este evento para controlar la navegacin. El mtodo de salida debe ser un procedimiento de clase de Diccionario de Datos de la tabla. Por ejemplo si tiene el siguiente procedimiento:
Procedure AdjustDisplayTotal Interger iField Interger iValue // This updates the extender Price field, which will update any // display balances.This is only done for display purposes.The // actual amount is updated to the field during the save. Interger iQty Number nAmnt Get Field_Current_Value Field Orderdtl. Qty_Ordered to iQty Get Field_Current_Value Field Orderdtl.Price to nAmnt Set Field_Current_Value Field Orderdtl. Extended_Price to (nAmnt * iQty) // note we set value, but not changed state! End_Procedure
www.VisualDataflex.es
Pgina 52 de 92
Set Field_Exit_msg Field Orderdtl.Qty_Ordered to Adjust_Display_Total El prototipo de declaracin para un mtodo de salida tiene el siguiente formato general.
procedure procedureName integer iField type currentValue Dnde: procedureName es el nombre del procedimiento; iField es el nmero del campo que envi procedureName. El nmero de campo puede usarse para obtener cualquier informacin sobre el campo. Type y currentValue son el tipo y el valor actual del campo que envi procedureName.
Los parmetros que se pasan al mtodo de salida permiten que escriba procedimientos generalizados que pueden ser reutilizados en otros campos y tablas.
Consulte lo siguiente
Definir los atributos de campo de Diccionario de Datos.
www.VisualDataflex.es
Pgina 53 de 92
Define_Auto_Increment ordsys.last_cust_num to Customer.cust_number Send Add_System_File ordsys.last_cust_num DD_LOCK_ON_NEW_SAVE_DELETE Puede usar una tabla padre relacionada si su identificador (ID) nico es multi - segmento. Por ejemplo el ID de una estructura Cabecera-Detalle como en pedido-detalle pedido. Por ejemplo, el ID de una tabla de Detalle (Order-Detail) en una estructura Cabecera-Detalle (header-detail) podra ser el nmero del documento (Cabecera) y un nmero de orden de detalle asignado por una tabla sistema. Si el ltimo nmero de detalle de cada cabecera fuera almacenado en la tabla Cabecera (OrderHea.Last_Detail_Num) el campo de Autoincremento se definira como:
Define_Auto_Increment OrderHea.Last_Detail_Num to OrderDtl.Detail_Number Solamente puede asignar un autoincremento campo por DDO. Si intenta atribuir dos, entonces de autoincremento del primer campo ser ignorado. Si tiene que asignar campos de autoincremento adicional dentro de su Diccionario de Datos puede hacerlo fcilmente aadiendo un cdigo personalizado al evento de Creating del Diccionario de Datos.
Consulte lo siguiente
Definir los atributos de campo de Diccionario de Datos.
www.VisualDataflex.es
Pgina 54 de 92
Consulte lo siguiente
Definir los atributos de campo de Diccionario de Datos.
www.VisualDataflex.es
Pgina 55 de 92
// Part of an order entry view // Object oOrderNumber is a dbForm Set Server to oOrderhea_DD Entry_Item Orderhea. Order_number //this is not a foreing field : Object oCustomerName is a dbForm Set Server to oOrderhea_DD Entry_Item Customer.Name/ this is a foreing field : Un ejemplo de un campo extranjero es el campo customer.Name cuando sale en un view del Order Entry. Esto es debido a que es la tabla Order-Header la que provee el servidor de Diccionario de Datos; la tabla cliente (customer) en este ejemplo es padre del Order-Header.
// Part of customer maintenance view // Object oCustomerName is a dbForm Set Server to oCustomer_DD Entry_Item Customer.Name// this is not a foreing field : Cuando el campo customer.Name sale en la vista del mantenimiento de clientes, no es un campo forneo porque en este caso la tabla del cliente provee el servidor de Diccionario de Datos. Cuando el nmero de la tabla (File-Number) de Entry_Item no es el mismo que el nmero de la tabla principal del Diccionario de Datos, la tabla debe ser un antepasado (padre, abuelo, etctera.). Si no lo es, probablemente, ha cometido un error. Los elementos de entrada de datos de tablas de ancestros (tablas padre, abuelo) se usan generalmente de forma diferente a la entrada de datos de la tabla principal. Cuando se introduce un registro nuevo en la principal, los registros de la tabla padre no se modifican. Su funcin es proporcionar valores de campo (nmero de cliente, forma de pago) en los que se basan las relaciones de la tabla principal a la tabla padre. Cuando se tiene que modificar la tabla padre
www.VisualDataflex.es
Pgina 56 de 92
Definiendo opciones de campo forneos para cada uno de estas categoras de campos (DD_KEYFIELD, DD_INDEXFIELD, DD_DEFAULT) proporciona a sus aplicaciones de introduccin de datos los elementos necesarios sin programacin adicional. Las propiedades de campo forneos se aaden cualquier propiedad de opcin regular de campo. Los siguientes ejemplos indican un uso tpico de opciones de campo forneas.
Set Field_Options field Customer.id to DD_NoPut DD_AutoFind DD_CapsLock Set Field_Options field Customer.balance_due to DD_DisplayOnly : // define default foreing field options Set Foreign_Field_Options DD_KEYFIELD to DD_FindReq Set Foreign_Field_Options DD_INDEXFIELD to DD_NoPut Set Foreign_Field_Options DD_DEFAULT to DD_DisplayOnly En este ejemplo, las opciones de campo regulan (campo no forneo) para Customer_ID sern No-Put, Auto-Find y Capslock. Sus opciones de campo forneo sern No-Put, Auto-Find, Capslock y puesto que es un campo clave, Find-Required. Todas las opciones de campo regulares se pueden asignar como opciones de campo forneos. En la prctica, las nicas opciones que probablemente vaya a poner son DD_NoPut, DD_NoEnter, DD_DisplayOnly, DD_AutoFind y DD_FindReq.
www.VisualDataflex.es
Pgina 57 de 92
Consulte lo siguiente
Definir Diccionario de Datos y atributos de campos forneos.
Set Foreign_Field_Options DD_INDEXFIELD to DD_NoPut Alternativamente, puede incluso decidir el que no se soporte bsquedas en estos campos, en cuyo caso los ajustes para estos campos forneos sern:
Consulte lo siguiente
Definir Diccionario de Datos y atributos de campos forneos.
www.VisualDataflex.es
Pgina 58 de 92
www.VisualDataflex.es
Pgina 59 de 92
Definiendo todas las tablas Padre con las que se est relacionando. Definiendo todas las tablas Hijo desde las que se est relacionando. Definiendo todas las tablas extra que puedan ser necesarias.
Una vez definido, sus objetos del Diccionario de Datos pueden usar esta informacin para verificar que las estructuras de DDO estn configurados adecuadamente para operaciones de grabacin y borrado.
Consulte lo siguiente
Definiendo tablas padre Definiendo tablas hijo Requisitos para las grabaciones Requisitos para los borrados Cmo funcionan las estructuras de DDO de grabacin. Tablas sistema y tablas externas
www.VisualDataflex.es
Pgina 60 de 92
Consulte lo siguiente
Definir relaciones externas Padre-hijo de Diccionario de Datos.
Consulte lo siguiente
Definir relaciones externas Padre-hijo de Diccionario de Datos.
www.VisualDataflex.es
Pgina 61 de 92
// Define_Fields in the customer DD class Procedure Define_Fields Forward Send Define_Fields set Main_File to Customer.File_Number : Send Add_Server_File Region.File_Number End_Procedure Ahora, la estructura del DDO de la lista de arriba ahora est incompleta. Est incompleta para Customer y por lo tanto est incompleta para OrderHea. No se admiten grabaciones en ninguno de los dos DDOs. Para que una estructura DDO sea vlida necesitara mostrarse as:
www.VisualDataflex.es
Pgina 62 de 92
Object oRegion_DD is a Region_DataDictionary End_Object // oCustomer_DD Object oCustomer_DD is a Customer_DataDictionary Set DDO_Server to oRegion_DD End_Object // oCustomer_DD Object oSalesp_DD is a Salesp_DataDictionary End_Object // oSalesp_DD Object oOrderhea_DD is a Orderhea_DataDictionary Set DDO_Server to oCustomer_DD Set DDO_Server to oSalesp_DD End_Object // oOrderhea_DD Note que Add_Server_File se emplea para definir una tabla padre requerida dentro de un Diccionario de Datos y que esto ocurre en el nivel de clase. El uso de DDO_Server crea la conexin en el nivel de objeto. Add_Server_File define el requisito y DDO_Server lo cumple.
Consulte lo siguiente
www.VisualDataflex.es
Pgina 63 de 92
Object oOrderhea_DD is a Orderhea_DataDictionary Set DDO_Server to oCustomer_DD Set DDO_Server to oSalesp_DD End_Object // oOrderhea_DD Object oOrderdtl_DD is a Orderdtl_DataDictionary Set DDO_Server to oOrderhea_DD End_Object // oOrderhea_DD Esta estructura de DDO ahora contiene los DDOs hijos requeridos y, por tanto, los borrados de los registros de OrderHea sern admitidos. Sin embargo estas estructuras, generalmente, no son tan simples. Si el DDO hijo (OrderDtl) contuviera tablas padre adicionales requeridas, entonces tienen que estar presentes esos DDOs hijos y sus respectivos DDOs padres. La estructura de DDO podra ser:
Object oVendor_DD is a Vendor_DataDictionary End_Object // oVendor_DD Object oInvt_DD is a Invt_DataDictionary Set DDO_Server to oVendor_DD End_Object // oInvt_DD Object oCustomer_DD is a Customer_DataDictionary End_Object // oCustomer_DD Object oSalesp_DD is a Salesp_DataDictionary End_Object // oSalesp_DD Object oOrderhea_DD is a Orderhea_DataDictionary Set DDO_Server to oCustomer_DD Set DDO_Server to oSalesp_DD End_Object // oOrderhea_DD Object oOrderdtl_DD is a Orderdtl_DataDictionary Set DDO_Server to oOrderhea_DD Set DDO_Server to oInvt_DD End_Object // oOrderdtl_DD
Consulte lo siguiente
Definir relaciones externas Padre-hijo de Diccionario de Datos.
www.VisualDataflex.es
Pgina 64 de 92
Modo de validacin
Set Validate_Save_Structure_Mode to DD_VALIDATE_STRUCTURE_ONCE Set Validate_Delete_Structure_Mode to DD_VALIDATE_STRUCTURE_ONCE Hay propiedades que le permitirn modificar la forma validar la estructura de grabar y borrar. Puesto que dentro de una aplicacin las estructuras de DDOs son generalmente estticas, normalmente slo se tiene que validar la estructura de grabacin y borrado una vez. Esto se efecta la primera vez que intenta grabar o borrar dentro de ese DDO. ste es el valor por defecto. Dinmicamente tendr que realizar esta validacin cada vez que quiera ejecutar una validacin o una grabacin. Aunque esto es poco habitual, est soportado para que lo pueda hacer en los casos en que los necesite. Tambin puede desactivar esta validacin, pero siempre con precaucin. Esto es un resumen de los modos de validacin: DD_VALIDATE_STRUCTURE_ALWAYS El Diccionario de Datos verificar las estructuras de tabla cada vez que un registro se grabe / se borre. Se desactiva la validacin estructuras de la tabla padre. de las
DD_VALIDATE_STRUCTURE_NEVER
DD_VALIDATE_STRUCTURE_ONCE
El error. El Diccionario de Datos verificar las estructuras de tabla la primera vez que se intente grabar despus de cargar la vista. Esto supone que la estructura no cambiar durante la sesin - normalmente una suposicin segura.
www.VisualDataflex.es
Pgina 65 de 92
Consulte lo siguiente
Definir relaciones externas Padre-hijo de Diccionario de Datos.
Send Add_System_File_ Ordsys.File_Number DD_LOCK_ON_NEW_SAVE_DELETE Define_Auto_Increment ordsys.last_cust_num to Customer.cust_number A menudo a las tablas de sistema no se les asigna un DDO sino que representan una excepcin de la regla que dice que una subclase de Diccionario de Datos debe crearse y usarse para cada tabla en una aplicacin. Puesto que las tablas de sistema contienen slo un registro que puede ser usado por muchos usuarios, hay un parmetro que optimiza y determina cundo debe bloquearse la tabla externa. Este parmetro tiene los siguientes valores:
DD_Lock_On_All
Se bloquea borrados.
en
todas
las
grabaciones
www.VisualDataflex.es
Pgina 66 de 92
DD_Lock_On_Save DD_Lock_On_New_Save
DD_Lock_On_Delete
Para tablas de sistema que soporten nmeros de serie de identificacin nicos, DD_Lock_On_New_Save debe ser suficiente; para tablas de contadores secundarios que incrementan y disminuyen, se necesitaran los otros dos modos por lo que DD_Lock_On_All sera apropiado. Note que esta optimizacin de bloqueo solamente se aplica a la Base de Datos embebida de DataFlex.
www.VisualDataflex.es
Pgina 67 de 92
Un evento puede ser usado por mltiples operaciones. Por ejemplo, el evento de Backout se convoca durante una grabacin y un borrado. El evento de Relate_Main_File puede ser convocado por las grabaciones, borrados, bsquedas y limpiar (Clear). Algunos eventos se convocan siempre en un estado de bloqueo (Ej. Update y Backout) mientras que los dems eventos pueden (o no) ser convocados en un estado de bloqueo (Ej. Relate_Main_File). Los eventos predefinidos del Diccionario de Datos son: Attach_Main_File Backout Clear_Main_File Creating Delete_Main_File Deleting Field_Defaults OnNewCurrentRecord Relate_Main_File Save_Main_File Update Validate_Delete
www.VisualDataflex.es
Pgina 68 de 92
// correct Procedure Update Forward send Update Move (Customer.due + order.total) to Customer.due End_Procedure
Consulte lo siguiente
Definir clases de Diccionario de Datos.
www.VisualDataflex.es
Pgina 69 de 92
Attach_Main_File
Attach_Main_File lleva a cabo un attach. Se llama durante operaciones de grabacin y borrado. Un Attach mueve los campos de datos relacionados de una tabla padre al DDO de una tabla hija. Esto asegura que los valores de relacin entre tablas se mantengan actualizados correctamente. Note que este Attach solamente se aplica a los DDOs padre que estn relacionados con este DDO. Si una tabla padre est relacionada con el de la tabla principal (Main Table) DDO pero no hay un padre DDO conectado al DDO, no ocurrir ningn Attach. Puede usar este procedimiento parea crear Attaches adicionales, cancelndolos todos o creando unos propios. La siguiente muestra efecta un Attach normal a no ser que uno de los Attach de campo se ignora.
Procedure Attach_Main_File String sTempVal Move Vndr.Parent_Stat to sTempVal / / remember this value // El Attach normal har un Attach de todas las Tablas padre // Incluyendo un Attach a Vndr.Parent_Stat. Queremos // ignorar este Attach Forward Send Attach_Main_File Move sTempVal to Vndr.Parent_State / / Deshaga este Attach End_Procedure Note que Attach_Main_File y Relate_Main_File no son verdaderos inversos entre ellos. Relate_Main_File no hace nada (la relacin sucede como parte del Find). Attach_Main_File lleva a cabo el comando Attach. Si no hace un Forward send del mensaje, el Attach no ocurrir. Cuando acceda a los valores de la tabla deber acceder a al Buffer global de la tabla y no al Buffer local del DDO (es decir, use la sintaxis de Move File.Field To Variable). Para ms informacin consulte Comprendiendo Buffer de ficheros y Buffers de DDOs.
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Backout y Update
Los eventos de Update y Backout se usan para mantener balances de relacin entre tablas. Update es llamado en las modificaciones y altas de registros, mientras que Backout es llamado en las modificaciones y borrados de registros. Update y Backout se emplean generalmente para ajustar las tablas padre. Backout, concretamente, se emplea para eliminar el efecto de una grabacin mientras que la Update se usa para aadir el efecto de una grabacin.
www.VisualDataflex.es
Pgina 70 de 92
Procedure Update Forward Send Update Move (Checks.Total.+ Vndr.Total_Paid) to Vndr.Total_Paid End_Procedure Procedure Backout Forward Send Backout Move (Checks.Total- Vndr.Total_Paid) to Vndr.Total_Paid End_Procedure Cuando se graba un registro Nuevo (Alta) se llama Update (y no a Backout). Cuando se borra un registro (Elimina) se llama a Backout (y no a Update). Cuando se modifica un registro existente se llama a ambos (Update y Backout). La mayora de las veces los contenidos de Update y Backout sern el inverso de s mismos. Si no lo son, deber revisar su lgica de forma cuidadosa. La mayora de las veces lo que Update aada a un total, Backout se encargar de restarlo. Es posible que Backout y Update puedan ajustar totales de diferentes tablas padre durante una edicin. Esto ocurrira si la edicin causase que el Registro padre cambie. Los DDOs soportan esto. No asuma que los eventos de Update y Backout solamente se envan una vez durante una grabacin. Si el Registro padre de un Registro hijo no se cambia, entonces Backout y Update se llaman una sola vez. En caso de que se cambie el Registro padre de un Registro hijo, entonces Backout y Update se llaman ms de una vez. Por ejemplo: supongamos que nuestra tabla de clientes est relacionada con una tabla de zonas geogrficas de forma que un cliente pertenece a una zona y una zona tiene mltiples clientes. En este caso, nuestra tabla hijo es la tabla de clientes y la tabla padre es la de zonas. Supongamos que en la tabla de zonas llevamos un total de ventas de cada zona que es la suma de las ventas de cada uno de los clientes de esa zona. Si a un cliente le cambiamos de zona (a un Registro hijo le cambiamos el padre) entonces Update y Backout se llaman ms de una vez. El proceso de mantener integridad relacional cuando se cambia el registro padre de un hijo es bastante complejo y ambos eventos pueden ser llamados mltiples veces para la misma tabla (para diferentes registros). Si un cambio en un registro debe ajustar totales en un Registro padre y abuelo (Ejemplo: el importe de una lnea ajusta los totales de la factura, y esta a su vez el crdito consumido del cliente), es mejor dejar que un Diccionario de Datos acte sobre su padre(s) inmediato(s) (lneas sobre factura y factura sobre cliente). Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones.
www.VisualDataflex.es
Pgina 71 de 92
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Clear_Main_File
Clear_Main_File efecta un clear sobre la tabla principal del Diccionarios de Datos. Normalmente, querr realizar un Forward send de este mensaje y despus cualquier tipo de aumento. Si desea que este evento limpie (clear) una tabla adicional debe contar el Diccionario de Datos sobre esto enviando el mensaje Request_Clear_File:
Procedure Clear_Main_File Forward Send Clear_Main_File Clear AuxFile Send Request_Clear_File AuxFile.File_Number End_Procedure Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Creating (crear)
Creating es llamado como parte del proceso de grabacin y se llama cuando se va a grabar un nuevo registro. El comportamiento por defecto de este evento es para manejar Autoincrementos cuando este est definido en la clase con el comando Define_Auto_Increment. Por este motivo debe asegurarse reenviar el evento (Forward send) Este evento puede usarse para efectuar cualquier procesamiento adicional requerido para un nuevo registro.
www.VisualDataflex.es
Pgina 72 de 92
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Delete_Main_File
El evento de Delete_Main_File efecta el borrado (delete) del registro. Delete_Main_File est pensado para aumentarse Normalmente, querr siempre reenviar (Forward send) este mensaje. Si no se reenva no se borra el registro. Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones. Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Consulte lo siguiente
Definir eventos de Diccionario de Datos
Deleting (borrar)
Deleting se llama durante el proceso de borrado (delete). Se enva antes del mensaje de Backout.
Procedure Deleting Forward send Deleting Send LogDeletedRecord End_Procedure Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento.
www.VisualDataflex.es
Pgina 73 de 92
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Field_Defaults
El evento de Field_Defaults sirve para soportar los ajustes de los valores por defecto despus de un Clear. Puede fijar cualquier valor de campo, que se reflejar en los DEOs y ser guardado con el registro nuevo. Puesto que el ajuste de los valores por defecto se codifican en un procedimiento, se pueden crear reglas complicadas. El ajuste de un valor por defecto no es reconocido como un cambio de datos por el Diccionario de Datos; por lo tanto, el ajuste de los valores por defecto no generar un mensaje de aviso de "prdida de datos".
Procedure Field_Defaults Forward Send Field_Defaults Set Field_Changed_Value field Customer.State to FL Set Field_Changed_Value field Customer.Discount to (Discount(self)) Set Field_Changed_Value field Customer.City to "Miami" End_Procedure Los valores por defecto tambin pueden fijarse a la entrada de un DEO creando un mtodo Field Entry y ponindolo con la propiedad de Field_Entry_msg. Ese mtodo podra poner el valor por defecto usando el mensaje de Field_Default_Value.
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
www.VisualDataflex.es
Pgina 74 de 92
Procedure OnNewCurrentRecord RowId riOldRec RowId riNewRec Forward Send OnNewCurrentRecord riOldRec riNewRec // Asumiendo que deseamos atrapar grabaciones de registros nuevos If (Operation_Mode = Mode_Saving AND ; IsSameRowId (riOldRec, riNewRec)) Begin : End Else.... End_Procedure
Notas especiales
Este mensaje debe ser reenviado (Forward Send). Este evento no existe en la versin 10.1 de Visual DataFlex. En vez de dicha versin se emplea el New_Current_Record. A este evento se le pasan los nmeros de registro (Integers) en lugar de RowIds. El evento de New_Current_Record todava se convoca pero se considera obsoleto. On new current Record es su sustituido preferido.
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Relate_Main_File
Por defecto, Relate_Main_File no hace nada. Ocurre despus de que el Relate normal se haya ejecutado. Es un evento que permite ejecutar relaciones personalizadas despus de que su registro principal se haya encontrado y relacionado. Si va a encontrar registros nuevos en Relate_Main_File, debe notificar que el DDO ha encontrado este nuevo registro. Esto se hace enviando el mensaje de Request_Relate (si se encuentra el
www.VisualDataflex.es
Pgina 75 de 92
Procedure Relate_Main_File Boolean bMustFind Integer iFile iStatus Get Main_File to iFile Get_Attribute DF_FILE_STATUS of iFile to iStatus Forward Send Relate_Main_File If (iStatus = DF_FILE_INACTIVE) begin Move True to bMustFind end Else if (Vndr.Soft_id <>SoftFile.Soft_id) begin Move True to bMustFind end If bMustFind Begin / / Solamente relaciona SoftFile si es necesario Clear SoftFile Move Vndr.Soft_ID to SoftFile.Soft_Id Find eq.SoftFile.Soft_Id End Get_Attribute DF_FILE_STATUS of SoftFile.File_Number to iStatus If (iStatus<>DF_FILE_INACTIVE) begin Send Request_Relate SoftFile.File_Number End Else begin Send Request_Clear_File SoftFile.File_Number End End_Procedure Note la optimizacin de este procedimiento. La bsqueda en SoftFile se lleva a cabo slo si: el Buffer de SoftFile est vaco o si el registro en el Buffer no es el que queremos (los valores relacionados no son los mismos). Se recomienda optimizar sus bsquedas dentro de Relate_Main_File. Debido a que los DDOs no pueden saber qu est haciendo este procedimiento, no hay, tampoco, ninguna manera de optimizar estas bsquedas. En el momento en que un DDO piense que la relacin personalizada de un registro pudiese ser incorrecta, enviar Relate_Main_File. Esto sucede a menudo. Por eso es importante que optimice sus bsquedas (un proceso sencillo) para no ralentizar sus operaciones de base de datos. Preste atencin pues Relate_Main_File no siempre encuentra registros que se relacionan con el registro actual. Cuando se cambia el registro padre de un registro hijo, Relate_Main_File se llamar durante el proceso de grabacin para encontrar registros relacionados con el padre
www.VisualDataflex.es
Pgina 76 de 92
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Save_Main_File
Save_Main_File sirve para grabar el fichero principal. Puede usar Save_Main_File para tablas adicionales no relacionadas o para procesar cambios adicionales en su tabla. Save_Main_File se llama para cada tabla que se graba en una operacin del Diccionario de Datos. Este mtodo puede llamarse incluso si no hay ningn cambio para grabar. En tal caso, la grabacin fsica en la base de datos no ocurrir aunque se llame el evento. En este ejemplo, queremos grabar la fecha y hora en cada registro grabado. Puesto que fijar la fecha y la hora en un campo puede causar que un registro no modificado se grabe, nicamente cambiaremos dicho valor si se modifica el registro. Si se modifica el Buffer del fichero, marcaremos el registro con la fecha y hora.
Procedure Save_Main_File Boolean bChanged Interger iFile Get Main_File to iFile Get_Attribute DF_FILE_CHANGED of iFile to bChanged // Solamente marcamos el registro si este se ha modificado. Esto asume // que las funciones Crnt_Date y Crnt_Time ya existen. If (bChanged) Begin / / if record is changed at all Get Crnt_Date to Vndr.Date_Stamp Get Crnt_Time to Vndr.Time_Stamp End // now do the normal save behavior Forward Send Save_Main_File End_Procedure Normalmente, siempre haremos un Forward Send de este mensaje. Si el mensaje no se enva, la grabacin no tendr lugar. Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones.
www.VisualDataflex.es
Pgina 77 de 92
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Update y Backout
Los eventos de Update y Backout se usan para mantener balances de relacin entre tablas. Update es llamado en las modificaciones y altas de registros, mientras que Backout es llamado en las modificaciones y borrados de registros. Update y Backout se emplean generalmente para ajustar las tablas padre. Backout, concretamente, se emplea para eliminar el efecto de una grabacin mientras que la Update se usa para aadir el efecto de una grabacin. Los siguientes Update y Backout en un Diccionario de Datos ajustaran los totales de su padre, la tabla vndr.
Procedure Update Forward Send Update Move (Checks.Total.+ Vndr.Total_Paid) to Vndr.Total_Paid End_Procedure Procedure Backout Forward Send Backout Move (Checks.Total- Vndr.Total_Paid) to Vndr.Total_Paid End_Procedure Cuando se graba un registro Nuevo (Alta) se llama Update (y no a Backout). Cuando se borra un registro (Elimina) se llama a Backout (y no a Update). Cuando se modifica un registro existente se llama a ambos (Update y Backout). La mayora de las veces los contenidos de Update y Backout sern el inverso de s mismos. Si no lo son, deber revisar su lgica de forma cuidadosa. La mayora de las veces lo que Update aada a un total, Backout se encargar de restarlo. Es posible que Backout y Update puedan ajustar totales de diferentes tablas padre durante una edicin. Esto ocurrira si la edicin causase que el Registro padre cambie. Los DDOs soportan esto. No asuma que los eventos de Update y Backout solamente se envan una vez durante una grabacin. Si el Registro padre de un Registro hijo no se cambia, entonces Backout y Update se llaman una sola vez. En caso de que se cambie el Registro padre de un Registro hijo, entonces Backout y Update se llaman ms de una vez. Por ejemplo: supongamos que nuestra tabla de clientes est relacionada con una tabla de zonas geogrficas de forma que un cliente pertenece a una zona y una zona tiene mltiples clientes. En este caso, nuestra tabla hijo es la tabla de clientes y la tabla padre es la de zonas. Supongamos que en la tabla de zonas Pgina 78 de 92
www.VisualDataflex.es
Consulte lo siguiente
Definir eventos de Diccionario de Datos
Validate_delete
La funcin Validate_Delete se llama justo antes de que tenga lugar un borrado. Se bloquean todas las tablas que participan en el borrado. Si se genera un error o se devuelve un valor distinto de cero, se detiene el borrado. Una operacin de borrado eliminar el registro de la tabla principal y todos los registros relacionados de las tablas descendientes (hijos, nietos, etc). Esto se hace para evitar registros hurfanos. Esta comprobacin solamente ocurre si Cascade_Delete_State es verdadero y si hay una relacin padre- hijo entre tablas y la estructura de DDO es correcta. El Validate_Delete solamente se enva al DDO de la tabla principal sobre la que se quiere efectuar el borrado. Si se aprueba el Validate_Delete, el registro de la tabla principal y todos sus registros hijos sern eliminados. Si est prohibiendo supresiones en cascada, es esencial que enve (Forward Send) el mensaje Validate_Delete. La verificacin del borrado en cascada sucede como parte de este envo (Forward Send):
Function Validate_Delete returns Integer Integer iError Forward get Validate_Delete to iError If (not (iError)) Begin If (Customer.status = "A") Begin Error 306 Cannot delete active record End
www.VisualDataflex.es
Pgina 79 de 92
Consulte lo siguiente
Definir eventos de Diccionario de Datos
Validate_Save
Validate_Save se usa como la validacin final de un registro antes de grabarlo. Se enva a cada tabla en la estructura de DDO que participar en la grabacin. Ocurre cuando la base de datos est bloqueada y todos los valores de campo han sido actualizados. Puede consultar directamente el valor de cualquier buffer de fichero.campo y si cualquier valor o combinacin de valores son invlidos, puede detener la grabacin declarando un error o devolviendo un valor distinto de cero. Los datos en el buffer del fichero son exactamente los que van a ser grabados. La excepcin para esto es que los attach del buffer del fichero no han ocurrido todava. Esto quiere decir que un buffer de una tabla hijo podra no contener la informacin del padre para poner en el amortiguador de archivo durante el evento Attach_Main_File. El evento Attach_Main_File ocurre despus de Validate_Save. Todas las tablas de los DDOs participantes se bloquean durante Validate_Save. Por lo tanto, la funcin debe ser rpida y no debe requerir nunca una introduccin de datos por parte del usuario. La excepcin de esto es el comando de Error. Un error generado durante el Validate_Save ser diferido hasta que las operaciones de grabacin hayan retrocedido (Roll Back) y las tablas hayan sido desbloqueadas.
www.VisualDataflex.es
Pgina 80 de 92
Function Validate_Save returns Integer integer iError If (Invt.Qtv < 0) Begin Error DFERR_OPERATOR "Insufficient Inventory on hand' End Forward get Validate_Save to iError Function_Return iError End_Function Un error en cualquiera de los eventos de grabacin (Validate_Save, Update, Backout, Save_Main_File, etctera.) indica un retroceso de la transaccin (Transaction Roll Back). ste es un proceso especial. Cuando esto ocurra el cdigo pendiente de ejecutarse de la funcin no se procesar. Debido a que los buffers para todas las tablas que estn participando han sido actualizados, no deber buscar (find), limpiar (clear), borrar (delete) o modificar ningn buffer de fichero. Esto no debe de confundirse con la validacin de campo (Field Validation). La validacin de campo ocurre antes de que la base de datos se bloquee y antes de que los campos sean actualizados en el buffer del fichero. La validacin de campo puede usarse para manejar la mayora de las validaciones. Validate_Save se emplea, solamente, para manejar validaciones especiales que solamente puedan ser comprobadas en un estado de bloqueo y con datos actualizados. Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuacin por parte del usuario en este evento. Si declara un error, la transaccin se deshar (Roll back). Los errores deben generarse usando el comando de error. Para ms informacin consulte Manejo de error en las transacciones. Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO (debe usar la sintaxis del tipo Move File.File to Var). Para ms informacin consulte Comprendiendo Buffers globales y Buffers locales de DDO.
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
www.VisualDataflex.es
Pgina 81 de 92
filtros
Una restriccin (Constraint) es una limitacin sobre los registros de una tabla que van a ser visibles para un componente del programa (ej: una vista, un objeto de Web, un informe). Hay dos razones por las que podra querer limitar los registros en un DDO:
Cuando un DDO se relaciona con otro. Podra querer que el DDO hijo solamente mostrase los registros que se relacionan con el DDO padre. Esto se denomina restriccin relacionada con Relates-To Constraint. Una vista o un informe puede estar centrado en un subconjunto de registros. Podra especificar de qu clientes y de qu regiones se muestra la informacin. Esto se denomina Filtros por restriccin (Filter Constraints).
Consulte lo siguiente
La restriccin a la hora de desarrollar el proceso. Herencia de las restricciones. Optimizacin de la bsqueda de las restricciones.
www.VisualDataflex.es
Pgina 82 de 92
Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is A OrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number End_Object / / oOrderHea_DD Los Diccionarios de Datos manejan las restricciones relacionadas de una manera muy especial. Cuando una restriccin relacionada est activa, las reglas de propagacin para Buscar (Find) y limpiar (Clear) son diferentes. Esto se comenta con detalle en Propagacin de DDO y restricciones relacionadas. Se deben cubrir varios requisitos para que las restricciones relacionadas funcionen de forma apropiada: Una relacin debe estar definida entre la tabla hijo y la tabla padre. Dicha relacin debe definirse dentro de Database Builder. Esto requiere que la tabla hijo defina el campo o los campos que se relacionan con su correspondiente conjunto de campos en la tabla padre. El valor del campo/campos con los que est relacionado en la tabla padre deben de ser nicos e identificar un registro. En definitiva, esos campos con los que est relacionado deben de formar un ndice por s mismos. La tabla hijo deber tener uno o ms ndices que permitan Bsquedas rpidas por los campos relacionados. Esto quiere decir que los primeros segmentos en esta tabla hijo deben contener los campos relacionados. El DDO hijo debe de estar apropiadamente conectado con el DDO padre, poniendo la propiedad de DDO_Server en el hijo.
Las reglas 1 y 2 son reglas estndar usadas para definir cualquier relacin padre-hijo de forma correcta. La regla 3 hace posible que los DDOs encuentren, rpidamente, registros relacionados.
www.VisualDataflex.es
Pgina 83 de 92
Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is A OrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number End_Object / / oOrderHea_DD Las restricciones relacionadas se puede aplicar en mltiples niveles. En el siguiente ejemplo, los pedidos (orders) son restringidas a clientes y los detalles del pedido (Order-Detail) restringidas al pedido. Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is A OrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number End_Object / / oOrderHea_DD Object oOrderDtl_DD Is A OrderDtl_DataDictionary Set DDO_Server To oOrderHea_DD Set Constrain_File To OrderHea.File_Number End_Object / / oOrderDtl_DD Estas clases de restricciones se usan habitualmente en informes y en entrada de datos tipo cabecera-detalle. Por ejemplo, encontrara primero un cliente luego un pedido (que es el hijo del cliente), posteriormente encuentra los detalle del pedido que son hijos del pedido.
www.VisualDataflex.es
Pgina 84 de 92
Consulte lo siguiente
Restricciones y filtro.
www.VisualDataflex.es
Pgina 85 de 92
Restricciones de filtro
Las restricciones de filtro representan todas las restricciones no relacionadas y que sirven para filtrar los registros por cualquier conjunto de restricciones. Las restricciones de filtro se definen dentro de un DDOs en el mtodo OnConstrain y son especificadas dentro de este mtodo usando el comando de Constrain. Object oCustomer_DD Is A Customer_DataDictionary Procedure OnConstrain Constraint Customer.Status Eq "A" End_Procedure End_Object / / oCustomer_DD Las restricciones de filtro son aditivas. Si se definen mltiples restricciones dentro de un evento de OnConstrain, se deben cumplir todas las restricciones para encontrar un registro. Las restricciones de filtro tambin se aaden a restricciones relacionadas. En el siguiente ejemplo, solamente se encontrarn las rdenes si: se estn relacionado con el cliente en curso, i el tipo de orden es N, y si la empresa de transporte es FEDEX:
Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is A OrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number Procedure OnConstrain Constrain OrderHea.Shipper eq "FEDEX" Constrain OrderHea.Type eq N End_Procedure End_Object / / oOrderHea_DD Las restricciones del DDO padre las heredan sus DDOs hijos. Puede que este comportamiento por defecto no sea siempre deseado y puede ser desactivado configurando la propiedad de pbInheritConstraints a falso.
www.VisualDataflex.es
Pgina 86 de 92
Constrain OrderHea.Shipper eq "FEDEX" Get pbLowerDate to dLowerDate Constrain OrderHea.Date gt dLowerDate Get psStatusConstraint to sStat If (sStat<> "") Begin Constrain Customer.Status eq sStat End Los filtros de campo se crean y se evalan cuando se crea una restriccin y no cada vez que se encuentra un registro. Esto tiene ciertas ventajas. Debido a que el motor de restriccin sabe qu campo est siendo filtrado y qu tipo de evaluacin est siendo aplicada, es capaz de determinar si la restriccin, teniendo en cuenta el ndice usado para la bsqueda, puede ser optimizado. Si puede ser optimizado, la bsqueda del registro mucho ms rpida.
El filtro Constrain-As
El filtro Constrain-As se emplea para especificar que el registro se ajuste a unos criterios definidos por una expresin. Tiene el formato general de:
Constrain Customer As (Uppercase(Customer.Name) Contains "DATA") Constrain Customer As ( (Customer.Name Contains "DATA") Or ; ( (Customer.Type = "COMPUTER") And ; (Customer.Area_Code Matches "3?5") )) Constrain Customer As (TestValidity(Self)) La expresin debe devolver un valor de verdadero o falso. Si es verdadero, el registro es vlido y si no es filtrado. La restriccin de expresin (Expresion Constraint) es la ms flexible. Puede escribir cualquier expresin que desee, de cualquier nivel de complejidad. Generalmente, usar las expresiones de comparacin con And/Or. Tambin puede llamar a las funciones dentro de la expresin. Sin embargo, debido a su flexibilidad, esto es tambin el tipo de restriccin ms lento. La expresin se evala cada vez que se encuentra un registro. Adems, debido a que el motor de restriccin no tiene ni idea de qu est haciendo en realidad la expresin, una restriccin de expresin no puede
www.VisualDataflex.es
Pgina 87 de 92
Object oCustomer_DD Is A Customer_DataDictionary End_Object / / oCustomer_DD Object oOrderHea_DD Is AOrderHea_DataDictionary Set DDO_Server To oCustomer_DD Set Constrain_File To Customer.File_Number Procedure OnConstrain Constrain OrderHea.Type eq N" Constrain OrderHea (OrderHea.Shipper= "FEDEX" or OrderHea.Shipper=UPS) End_Procedure End_Object / / oOrderHea_DD
Consulte lo siguiente
Restricciones y filtros.
www.VisualDataflex.es
Pgina 88 de 92
Object Customer_DD is a Customer_DataDictionary Property String psStatusConstraint Procedure ConstraintByStatus string sStar integer iIndex Set psStatusConstraint to sStat Send Rebuild_Constraints Send Find FIRST_RECORD iIndex End_Procedure Procedure OnConstrain Sting sStat Get psStatusConstraint to sStat If (sStat<> "") Begin Constrain Customer.status eq sStat end End_Procedure End_Object
Consulte lo siguiente
Restricciones y filtros.
www.VisualDataflex.es
Pgina 89 de 92
Object oVendor_DD is a Vendor_DataDictionary End_Object // oVendor_DD Object oInvt_DD is a Invt_DataDictionary Set DDO_Server to oVendor_DD Procedure OnConstrain Constrain invt.Unit_price gt 100 End_Procedure End_Object // oInvt_DD Object oCustomer_DD is a Customer_DataDictionary End_Object // oCustomer_DD Object oSalesp_DD is a Salesp_DataDictionary End_Object // oSalesp_DD Object oOrderhea_DD is a Orderhea_DataDictionary Set DDO_Server to oCustomer_DD Set DDO_Server to oSalesp_DD End_Object // oOrderhea_DD Object oOrderdtl_DD is a Orderdtl_DataDictionary
www.VisualDataflex.es
Pgina 90 de 92
Set pbInheritConstraints to False Procedure OnConstrain // La tabla del Constrain DEBE de ser el nombre del DDO de la tabla principal // pero la expresin puede referirse a un DDO padre Constrain OrderDtl AS (Invt.Active="A") End Algunos desarrolladores prefieren usar esta tcnica porque guarda todas las restricciones para un DDO en un nico sitio (Ej. No tiene que buscar en el DDO padre para filtros adicionales).
Consulte lo siguiente
Restricciones y filtros
www.VisualDataflex.es
Pgina 91 de 92
Object oOrderHea_DD is an OrderHea_DataDictionary End_Object Object oOrderDtl_DD is an OrderDtl_DataDictionary Set DDO_Server to oOrderHea_DD Set Constrain_File to oOrderHea.File_Number Set Ordering to 1 // este es el nico ndece que puede ser optimizado End_Object
Consulte lo siguiente
Restricciones y filtros.
www.VisualDataflex.es
Pgina 92 de 92