Transaccion
•Download as PPS, PDF•
0 likes•1,037 views
Este documento describe los aspectos fundamentales del diseño de transacciones en GeneXus, incluyendo la estructura, base de datos, definición de transacciones, nomenclatura de atributos, tipos de datos, dominios, formularios GUI, reglas y generación de ayuda. Un ejemplo detallado explica el proceso de emisión de facturas.
![Características ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Transaccion
Similar to Transaccion (20)
More from Carlos Salcedo Mena
More from Carlos Salcedo Mena (6)
Recently uploaded
Recently uploaded (20)
Transaccion
- 1. DISEÑO DE TRANSACCIONES
- 4. Estructura de la Transacción de Facturas en GeneXus
- 10. Nomenclatura GIK – Nombre de Atributo Categoría Semántica (1 a 3) Objeto ( 1 a 6 ) Calificador (1 a 3) Calificador (1 a 3) Complemento (texto libre)
- 11. Ejemplo de Nomenclatura GIK Objeto Categoría Calificador Cli Cli Cli Cli FacVta FacCmp Cod Nom Fch Fch Nro Nro Ini Fin
- 17. Form GUI-Windows de la transacción de Facturas
Editor's Notes
- El análisis de la aplicación comienza con la definición de las transacciones. Las transacciones son el objeto GeneXus a partir del cuál se extraerá el conocimiento necesario para diseñar la base de datos, por lo cual es uno de los objetos más importantes, y primero en diseñarse. A partir de las estructuras de las transacciones, GeneXus diseña la base de datos normalizada. Además de tener por objetivo la definición de la realidad y la consecuente creación de la base de datos normalizada, por cada transasacción se generará un programa asociado, que permitirá dar altas, bajas y modificaciones en forma interactiva a la base de datos. Así que además de determinar una estructura de tablas, permite trabajar sobre estas tablas, actualizando sus registros en forma interactiva. Podemos decir que las transacciones abarcan múltiples aspectos: a partir de ellas se infiere la estructura física que tendrá la base de datos determinan una interface para dar altas, bajas y modificaciones se les programa comportamientos particulares
- Algunas características de las transacciones, que iremos viendo en este manual, son: Estructura : Atributos que conforman la transacción (campos). A partir de ellos GeneXus inferirá las tablas que integrarán la base de datos. Form GUI-Windows : Cada transacción contiene un form GUI-Windows (Graphical User Interface Windows) mediante el cual se realizarán las altas, bajas y modificaciones en ambiente Windows. Form Web : Cada transacción contiene un form Web mediante el cual se realizarán las altas, bajas y modificaciones en ambiente Web. Reglas : Con las reglas definimos el comportamiento particular de las transacciones. Por ejemplo, cuáles son los valores por defecto de los atributos, qué controles hay que realizar sobre los datos, etc. Subrutinas : Son rutinas locales a la transacción. Eventos : Las transacciones soportan la programación orientada a eventos. Este tipo de programación permite el almacenamiento de código ocioso el cual es activado luego de ciertas acciones, provocadas por el usuario o por el sistema. Propiedades : Características que se pueden setear para definir el comportamiento general de la transacción. Ayuda : Texto para la ayuda a los usuarios en el uso de la transacción. Documentación : Texto técnico que se incluye para ser utilizado como documentación del sistema. Form Classes : Cada objeto puede tener asociado más de un form, que pertenece a una determinada Form Class. Existen dos Form Classes predefinidas: Graphic y Text. Style asociado : puede asociarse un “estilo” a la transacción, es decir, un objeto GeneXus que se utiliza para definir estándares.
- La estructura define qué atributos integran la transacción y cómo están relacionados. Para poder definir esa estructura, debemos encontrar una forma de notación adecuada. En el ejemplo que figura arriba, mostramos la notación que utilizaremos (y más adelante la explicamos en detalle) . El ejemplo corresponde a una transacción para registrar facturas. C ada grupo de atributos encerrado entre paréntesis pertenece a un NIVEL de la transacción. Cada nivel definirá un grupo de atributos que deben operar en conjunto. Se ingresarán , eliminarán o modificarán conjuntamente en la base de datos. Cabe notar que el primer nivel queda implícito, y no necesita un juego de paréntesis. También es necesario definir, entre los atributos que integran cada nivel, un conjunto que actúe como identificador de cada instancia de ese nivel. Esto es, atributos cuyos valores son únicos. Notaremos a estos atributos con un asterisco. Este es en definitiva el concepto de clave primaria , por lo que en la elección de estos atributos debemos atender a todas las reglas correspondientes a su definición. El conjunto de atributos entre paréntesis representa la ocurrencia de varias instancias, para cada instancia del nivel anterior. En el ejemplo, una factura tiene varios productos. En este ejemplo estamos ante la presencia de una transacción de dos niveles.
- Esta pantalla corresponde a la de edición de la estructura de una transacción. La notación que vimos en la página anterior, y que utilizamos para definir conceptualmente la estructura de las transacciones, se traduce de forma directa a la notación que se muestra en la pantalla que aparece en la figura. Al digitar un asterisco (que utilizamos para denotar que cierto atributo pertenece a la clave primaria) automáticamente aparece un símbolo de llave antes del atributo. En el ejemplo, FacNro y ProdCod son los identificadores (cada cual en su nivel) en la transacción de Facturas. Por lo tanto, ambos atributos aparecen precedidos con el símbolo de llave. En la notación utilizada por GeneXus , el segundo nivel se muestra claramente en la estructura de la transacción, ya que aparece indentado con respecto al primero. Al digitar un paréntesis de apertura (que utilizamos para denotar que comienza otro nivel de la transacción) se produce automáticamente la indentación correspondiente. GeneXus cuenta con una ventana popup que se despliega al hacer clic con el botón derecho del mouse sobre el atributo con el que se está trabajando, y que permite hacer varias cosas con él, como editarlo, borrarlo, indicar que es clave (opción “Set key”), copiarlo, moverlo hacia la derecha, para especificar que debe estar en un segundo nivel, etc.
- Para minimizar la posibilidad de inconsistencia en los datos de las distintas tablas, GeneXus utiliza un proceso de normalización en el que determina en qué tablas debe residir cada uno de los atributos de la base de datos. La base de datos obtenida a partir de las especificaciones de transacciones estará en 3era. Forma Normal (3NF). Para ver cómo se realiza este proceso, utilizaremos como ayuda las dependencias funcionales que se derivan de la definición de la transacción. La definición de esta primera transacción determina las siguientes dependencias funcionales : FacNro CliCod FacNro , ProdCod ProdNom FacNro CliNom FacNro , ProdCod ProdPre FacNro FacFch FacNro , ProdCod FacLinCnt FacNro , ProdCod FacLinImp FacNro determina CliCod , CliNom y FacFch , ( FacNro { CliCod , CliNom , FacFch }) pues indicamos por medio del asterisco (llave) que FacNro era el identificador del primer nivel de la transacción . Por lo tanto, estas dependencias funcionales determinan una tabla con el siguiente diseño: FacNro * ( P or simplicidad de notación, utilizamos el asterisco CliCod para representar la clave primaria de la tabla física) CliNom FacFch
- Por otro lado: { FacNro , ProdCod } { ProdNom , ProdPre , FacLinCnt , FacLinImp } ya que para cada factura (identificada por FacNro ), ProdCod es el identificador del conjunto de atributos del segundo nivel. Estas últimas dependencias funcionales definirán otra tabla con el siguiente diseño : FacNro * (Aquí también estamos representando con * los ProdCod * atributos que pertenecen a la clave primaria de la ProdNom tabla física) ProdPre FacLinCnt FacLinImp es decir, una tabla cuya clave primaria será compuesta, y será la formada por los atributos FacNro (del primer nivel de la trn) y ProdCod (del segundo). Como resultado de la normalización anterior, diremos que la transacción de facturas tiene dos tablas asociadas (FACTURAS y FACTURAS1) cada una correspondiente a un nivel de la transacción: Observación : La clave primaria de las tablas asociadas a los niveles subordinados es la concatenación de los identificadores de los niveles superiores (en el ejemplo: FacNro ) con los identificadores del nivel (en el ejemplo: ProdCod ). FacNro CliCod CliNom FacFch FacNro ProdCod ProdNom ProdPre FacLinCnt FacLinImp
- La definición de dos nuevas transacciones, Clientes y Productos, ha determinado la aparición de nuevas dependencias funcionales. GeneXus diseñará las nuevas tablas que correspondan (CLIENTES y PRODUCTOS) y realizará las modificaciones necesarias en las ya existentes (FACTURAS y FACTURAS1) para considerar el conjunto total de dependencias funcionales. A las que ya teníamos, se agregan las siguientes dependencias funcionales: CliCod CliNom ProdCod { ProdNom , ProdPre, ProdStk } La siguiente dependencia funcional: FacNro CliNom se ha vuelto transitiva a partir de la existencia de las dep endencias funcionales: FacNro CliCod CliCod CliNom , p or lo que deberá modificarse la tabla FACTURAS (normalizando). Análogamente con la tabla FACTURAS1 y las dependencias funcionales: { FacNro , ProdCod } { ProdNom , ProdPre } ProdCod { ProdNom , ProdPre , ProdStk } Aquí tenemos que ProdNom y ProdPre dependen parcialmente de la clave primaria, lo que viola 3NF, por lo cual se eliminan de la tabla FACTURAS1.
- GeneXus establece las relaciones entre las tablas a partir de los nombres de atributos. De esta manera, las claves foráneas de las tablas que componen la base de datos quedan determinadas a partir de los nombres de los atributos. En el ejemplo de arriba, el atributo de nombre CliCod se encuentra en 2 transacciones. En la transacción Clientes está indicado como clave primaria , por lo tanto en la transacción de Facturas significa que es clave foránea ( GeneXus establece las relaciones por los nombres de los atributos). En conclusión, como resultado a nivel de la base de datos, el atributo CliCod quedará almacenado en la tabla asociada a la transacción de Clientes como clave primaria, y en la tabla asociada a la transacción de Facturas, quedará almacenado como clave foránea .
- ARTech ha definido un Standard para la nomenclatura de atributos: el GIK (Genexus Incremental Knowledge Base). Puede gustarnos más o menos que otros. Lo importante es que es el utilizado por la comunidad de usuarios GeneXus . Esto viabiliza la reutilización de conocimiento entre ellos. Nombre de atributo - > Objeto + Categoría + Calificador Objeto: es el nombre (truncado) de la transacción a la que pertenece el atributo. Categoría: es la categoría semántica del atributo. Calificador: puede n existir uno o dos calificadores. A partir de la versión 7.5 de GeneXus se permite indicar cuántos son los caracteres significativos para determinar la unicidad de los nombres de los objetos, atributos y tablas. Para ello , hay pre ferencias en el modelo de Diseño, que permiten modificar la cantidad de caracteres que se consideran significativos para identificar un nombre de atributo, objeto o tabla , respectivamente : Significant Attribute name length: determina el largo significativo para los atributos y los dominios. El valor predeterminado es 30, y el valor mínimo es 4 caracteres.
- Significant Table name length: determina el valor significativo para tablas, índices y data views (objeto GeneXus que estudiaremos más adelante). El valor predeterminado es 30, y el valor mínimo es 4 caracteres. Significant Object name length: determina el valor significativo para transacciones, work panels, web panels, prompts, menu, menu bar, reportes, procedimientos, y styles. El valor predeterminado es 30, y el valor mínimo es 6 caracteres. Estas son preferences del modelo de Diseño, y se acceden mediante File/Edit Model/Preferences La modificación del largo de atributos, tablas e índices no es válido cuando se utiliza como DBMS el AS/400, y cuando se utiliza DBF. Para el caso de DBF, no deben excederse los diez caracteres, tanto para tablas e índices, como para atributos.
- Para cada atributo se debe definir: Name : es el nombre del atributo, que se utiliza para identificarlo (utilizando la nomenclatura GIK). Description : La “ Descripción ” o más propiamente “ Nombre largo ” es un string que contiene una descripción ampliada del atributo. Debe ser un identificador global del atributo, que lo identifique bien con independencia del contexto, y principalmente debe ser entendible por el usuario final, ya que es con esta descripción que él va a interactuar en el GeneXus Query. Dado que deber ser un identificador global del atributo, no puede haber dos atributos con la misma descripción para evitar ambigüedad al momento de elegir el atributo (más bien la descripción) en el GeneXus Query. Relacionado con la “Descripción” están las opciones Title y Column Title que aparecen en el Tab “Advanced”. “ Column Title” permite definir el título para cuando el atributo se encuentre en una columna de un subfile. Por defecto, toma el título definido en Description. “ Title” permite definir el título (descripción) que aparecerá en cualquier estructura plana en la que se incluya al atributo, como ser el primer nivel de una transacción, o la parte fija de un work panel. Por defecto “Title” también toma el título definido en Description. Domain : permite asignar un dominio en el que se basa el atributo (se verá unas páginas más adelante). Type : tipo de atributo (Numérico, Alfanumérico, Fecha, Varchar, Long Varchar, Datetime). Length : largo del atributo. Decimals : número de posiciones decimales (en caso que el atributo sea numérico) Picture : formato del campo para la visualización en la entrada y salida. Por ejemplo, en campos Character, @! significa que todos los caracteres se aceptan y despliegan en mayúsculas. Value Range : rango de valores válidos para el atributo. Por ejemplo: 1:20 30: significa que el valor debe estar entre 1 y 20 o ser mayor que 30.
- VarChar Permite almacenar texto de largo variable (hasta M) . Su función, en contraposición al C haracter, es la de optimizar el almacenamiento en la base de datos. Definición: Varchar(M, N) M es el largo máximo posible que dependerá del DBMS. Si el largo asignado al atributo es mayor que el soportado por el DBMS se utilizará el máximo soportado. N es el largo promedio. Se utiliza para optimizar los accesos a disco en algunos DBMSs. La idea es que si el valor de un atributo varchar es menor o igual que N, se almacenan N caracteres (rellenados con blancos) en el registro del archivo y se utiliza un único acceso a disco para leerlo o grabarlo. En caso que el valor del atributo V archar sea mayor que N, se almacenan los primeros N en el registro del archivo y el resto en un área de overflow para lo cual es necesario un acceso adicional tanto para lectura como para escritura. Se le pueden aplicar todas las funciones y operadores existentes para el tipo de datos C haracter. El tipo de datos Varchar es equivalente al tipo Character en todos los sentidos salvo en la forma en que se almacena en la base de datos. Para los DBMS que no soportan este tipo de dato s se crea como Character.
- Long Varchar Permite almacenar una cantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, comentarios, etc. El largo que se le asigna es considerado el largo máximo (la implementación depende de la plataforma). Existen dos funciones para manipular este tipo de campos: GXMLines y GXGetMLi. DateTime Permite almacenar una combinación de fecha y hora (hasta el segundo). Definición: DateTime(M, N) M : Largo de la fecha. Valores posibles: 0, 8 y 10. N : Largo de la hora. Valores posibles: 2, 5 y 8. Los valores de M y N, no afectan la forma de almacenar el tipo de datos sino específicamente a la forma de aceptar o mostrar su contenido . En caso que M sea 0 (no se considera la fecha) para un campo que ha de ser ingresado, el valor de fecha a asignar será el mínimo soportado por el DBMS y reconocido como fecha vacía o nula en GeneXus . En caso que N sea distinto de 8 para un campo que ha de ser ingresado, los valores no aceptados (minutos o minutos y segundos) serán considerados en cero.
- El objetivo de los dominios es permitir usar definiciones de atributos genéricos y poder asociar cada atributo con su correspondiente dominio. En el ejemplo, el dominio Dirección es definido como Character de 30 . Los atributos dirección del banco, BcoDir , y del cliente, CliDir , son asociados a él. Por lo tanto, si en el futuro se cambia la definición de este dominio, los cambios van a ser automáticamente propagados a todos los atributos que pertenezcan al mismo . De esta forma los dominios pemiten un mayor nivel de abstracción en la definición de la aplicación.
- Para cada transacción, GeneXus crea un form GUI-Windows (Graphical User Interface Windows) y otro form para trabajar en ambiente Web. Ambos forms son creados por defecto, conteniendo todos los atributos incluidos en la estructura de la transacción. Estos forms pueden ser modificados. A través del form de la transacción (GUI-Windows o Web según el ambiente de trabajo) el usuario puede crear, modificar y eliminar registros. En el ejemplo se muestra un form GUI-Windows con 2 niveles, correspondiente a una transacción Facturas. GeneXus genera dos tipos de diálogo para las transacciones: campo a campo (ambiente GUI-Windows) y full-screen (ambiente Web). Diálogo campo a campo : cada vez que un campo es digitado inmediatamente se controla su validez. Diálogo full-screen : primero se aceptan todos los campos de la pantalla y luego se realizan todas las validaciones. SUBFILE
- A los efectos de permitir modificar los forms que GeneXus crea por defecto, existe una toolbar disponible , con los controles disponibles . Los controles se incluyen en los objetos, tienen un formato y un comportamiento determinado. Existen los siguientes tipos de controles para transacciones: Atributo : Se utiliza para incluir atributos o variables en el objeto en cuestión. Texto : Todo fragmento de texto fijo que se desee mostrar, debe colocarse utilizando uno o más controles de este tipo . Línea : Con este control se dibujan líneas rectas ( horizontales , verticales , diagonales). Recuadro : Permite definir recuadros de distintos tamaños y formas . Subfile : P ermite definir Subfiles en las pantallas ( como el que aparece en el form de la transacción de Facturas que vimos en la página anterior ) . Botón : permite incluir botones en la pantalla. Bitmap : permite inclu ir bitmaps. Tab : este control tiene una o varias páginas , cada una de las cuales tiene un title y un área útil donde se ponen los controles de esa página. Solo una de las páginas puede estar activa a la vez y es la que se puede ver, del resto solo se verá su título. Esto es útil para cuando se quiere dividir l a información que se maneja, en distintos grupos , de modo que las pantallas queden diseñadas de forma amigable al usuario. También existen otros controles, que no aplican a las transacciones sino a otros objetos GeneXus (Print Block, Tabla, Text block, Subfile FreeStyle, etc.).
- Un Tab Control tiene una o varias páginas (por defecto tiene dos). Cada página tiene un título y un área útil, donde se ponen los controles de esa página. Sólo una de las páginas puede estar activa a la vez y es la que se puede ver. Del resto sólo se verá su título. Se pueden agregar y eliminar páginas , con botón derecho sobre el Tab Control. Hide Tabs Para mostrar sólo la página activa y no mostrar los tabs. Util para la definición de Wizards.
- Para definir el comportamiento de las transacciones se utilizan las REGLAS (rules). Algunas reglas válidas para transacciones: Default : Se utiliza para definir valores por defecto para los atributos. Default( Atributo , ValorPorDefecto ); S e asigna al Atributo el ValorPorDefecto (variable, constante, atributo) si se e stá en modo Insert . S i el modo no es Insert, no se dispara la regla . Nota : Esta regla también es válida en reportes, procedimientos, work panels y web panels, pero solo pueden utilizarse variables y las funciones today, sysdate y date. Error : Sirve para definir los controles que deben cumplir los datos, por ejemplo si no queremos permitir que se ingres en clientes sin nombre: Error(‘No se permiten clientes sin nombre’)if null( CliNom ); Cuando se cumple la condición, null( CliNom ), se despliega el mensaje: ‘No se permiten clientes sin nombre’ en pantalla y no se permite continuar hasta que el usuario ingrese un nombre e n el campo CliNom o abandone la transacción. Otro ejemplo de utilización de l a regla de error() p uede ser p ara prohibir alguna de las modalidades de la transacción: Error(‘No se permite eliminar facturas’) if Delete; Con esta regla , si el usuario intenta realizar una eliminación, sale el mensaje de prohibición.
- Msg : Sirve para d esplega r un mensaje cuando se cumple la condición de disparo: Msg(‘ Ingresó un cliente sin nombre ‘) if null( CliNom ); Si se cumple la condición (null( CliNom )) se despliega el mensaje, pero a diferencia de la regla Error, aquí se permite proseguir. Noaccept : En una transacción, todos los atributos que pertenecen a la/s tabla/s asociadas a la transacción, por defecto son aceptados. Si queremos que un atributo de estas caracterísitcas no sea aceptado, entonces contamos con la regla Noaccept. Por ejemplo: N oaccept( FacFch ) if Update; No permite que se modifique la fecha de la factura en modo Update. Serial : Supongamos que la transacción Factura tiene la siguiente estructura: FacNro * CliCod CliNom FacFch FacUltLin ( FacLinNro * ProdCod ProdNom ProdPre ProdStk FacLinCnt FacLinImp ) Notar que el identificador del segundo nivel no es ProdCod , sino el atributo de nombre FacLinNro (Número de Línea de Factura). Al diseña r la tr a n sacción F actura , si ProdCod* se define como identificador único del segundo nivel, c on dicho diseño se represent a que en cada factura, no puede ingresarse el mismo producto en m á s de un renglón. Si es a es l a realidad a ser representada , es adecuado que ProdCod* sea identificador único en el segundo nivel. Si en cambio, se d e sea permitir que en una misma factura se pueda ingres ar un mismo producto en m á s de un renglón, ProdCod no debe ser identificador único del segundo nivel, sino que se debe definir un atributo FacLinNro (Número de Línea de Factura) que sea identificador único del segundo nivel, siendo ProdCod clave foránea.
- Si se desea entonces diseñar la Factura conteniendo el atributo FacLinNro (Número de Línea de Factura) como identificador único del segundo nivel, puede ser útil asignar por medio del sistema, números correlativos a dicho campo, definiendo la siguiente regla: serial( FacLinNro , FacUltLin , 1); El primer parámetro de la regla serial define cuál es el atributo a numerar automáticamente, en el segundo parámetro por su parte, debe indicarse un atributo cuya función es guardar el último valor asignado hasta el momento, y por último el tercer parámetro es para indicar el incremento (en este caso se incrementa de uno en uno). El segundo parámetro (en el ejemplo FacUltLin ) debe pertenecer a una tabla directamente superordinada (este concepto se verá más adelante) a la tabla que contiene el atributo que se numerará automáticamente ( FacLinNro ). La regla serial lo requiere así. En el ejemplo, se puede observar que FacUltLin se encuentra en la tabla de clave FacNro*, la cual es directamente superordinada respecto a la tabla que contiene el atributo a numerar ( FacLinNro). Es decir, cada factura tendrá en el cabezal, un atributo que contendrá el último número de línea asignado hasta el momento ( FacUltLin ) . La regla serial está implementada de forma tal que necesita este atributo (para fijarse el último número, sumarle 1, y asignar el próximo número a la nueva línea). Concluyendo, la sintaxis de esta regla es: Serial(<At1> , <At2> , Incremento); Su función es numerar correlativamente de forma automática el valor del atributo <At1> con el valor indicado por Incremento , cada vez que se agregue un nuevo registro a la tabla que contiene <At1> . <Att2> debe ser un atributo definido en una tabla directamente superordinada (qué es una tabla superordinada se definirá con precisión más adelante) a la tabla que contiene a <Att1>. El atributo <Att2> sirve primeramente para indicar el valor de comienzo para <Att1> , y <Att2> es actualizado automáticamente cada vez que se inserta un registro con el último valor asigado de <Att1>.
- Importante: A la regla serial, sólo la usamos para numerar líneas, no la utilizamos para numerar cabezales. Motivo: Para usar la regla serial, se requiere definir un atributo en un nivel directamente superior. Es decir, que si se quisiera numerar automáticamente a los clientes ( CliCod ) o las facturas ( FacNro ) utilizando la regla serial, deberíamos definir un nivel superior, con un atributo que guarde el último número asignado. Definiendo este diseño se podría utilizar la regla serial para numerar automáticamente cabezales, pero el problema sería que cada vez que se inserte una factura, la regla serial mantendría lockeado el registro de la tabla NUMERA que guarda el último número de factura asignado (para modificarlo). L a regla serial liberaría dicho registro r ecién cuando se confirme el cabezal de la nueva factura. En consecuencia, si otro usuario deseara dar de alta también una factura, no podría ....... no se podría facturar “a la vez” desde dos o más puestos de trabajo ! Este es el motivo por el cual no se debe usar la regla serial para numerar cabezales . Para numerar cabezales, implementaremos más adelante un procedimiento que numera automáticamente. Este procedimiento lockeará el registro únicamente un instante (para leerlo, sumarle 1 y grabarlo). Para numerar líneas (de una factura por ejemplo), sí podemos usar la regla serial , ya que no afecta a otros usuarios que la regla serial mantenga lockeado el cabezal correspondiente a dichas líneas. Es decir, que en este caso lo que se mantiene lockeado es el cabezal de “esa factura” (lo cual no nos afecta). NUMERA CLIENTES FACTURAS NumCod* NumUlt Estructura de la tabla NUMERA CLI 20 último nro de cliente asignado FAC 10 último nro de factura asignado Transacción Facturas: Reglas: FacNro * CliCod serial( FacNro, NumUlt, 1); CliNom equal( NumCod, ‘FAC`); FacFch NumCod NumUlt ( ProdCod * ProdNom …… ) La regla equal permite “asignar” un valor en caso de inserción y “filtrar” en caso de actualización o eliminación.
- Este esquema de ayuda aparece con la versión 7.5 de GeneXus , y permite seleccionar entre dos formatos: CHM y HTML. Por cada objeto/atributo/variable, se genera un documento HTML que contiene el texto de ayuda definido en GeneXus para el mismo. Cualquiera sea el formato de help elegido, se genera un directorio HELP bajo el directorio del modelo, en el que se crea un archivo con extensión HTML por cada objeto/atributo/variable que tenga ayuda. Si el formato elegido es CHM, se crea además un archivo de nombre APPHLP.CHM en el directorio del modelo, y un archivo de definición de proyecto (de extensión HHP) que será utilizado por el compilador de Help, para la generación del CHM. Luego de especificar y generar las aplicaciones, el HELP debe ser generado (a través de Build / Generate Help) y, en caso de seleccionarse el formato CHM, debe ser también compilado. Al seleccionar la opción Build/Generate Help se habilitará un wizard que permite inicializar algunas propiedades sobre el archivo que contendrá el help de la aplicación. Entre ellas el formato de help (CHM vs WEB), y en caso de elegir CHM, se solicita el path del compilador del help. El compilador de HELP viene con el Visual Studio, pero no se instala automáticamente, sino que hay que instalarlo por separado.
- Al crear un nuevo modelo aparecerá el diálogo que se muestra en la transparencia para definir las propiedades del mismo. Cada modelo tiene un ambiente principal, que se usa para la creación y reorganización de la base de datos y como ambiente por defecto para la generación de la aplicación. Además puede tener varios ambientes secundarios, que se definen en el tab de Environments . El ambiente principal es el que se define en el tab General . La información que debe definirse es: Sección Information Name : Nombre del modelo que se está creando. Type : Tipo de modelo (Prototipo, Producción, Backup). Language : Idioma (Inglés, Español, Portugués, Italiano, Chino). Sección Environment Language : Lenguaje de los soportados por GeneXus (C#, C/SQL, Java, RPG, Visual Basic, Visual FoxPro, Xbase for DOS) en el cuál se desea que sean generados los programas (tanto los programas de creación/reorganización de la base de datos, como los programas de la aplicación). User Interface : Tipo de interface que se desea utilizar para el ambiente principal (Win o Web Form) DBMS : Sistema Manejador de Base de Datos. Target Path : Directorio en el cual quedarán los programas generados (este directorio será creado bajo el directorio de la Base de Conocimiento). Los valores disponibles, tanto para User Interface como para el DBMS dependen del Language seleccionado.
- A continuación se muestra una tabla con los valores posibles para cada lenguaje: El botón Preferences permite configurar ciertas propiedades para el modelo (dependiendo del generador elegido, algunas propiedades a configurar serán distintas). El botón DBMS Options permite configurar la información requerida para el acceso a la Base de Datos (por ejemplo, Data Source, etc.). El botón Execution permite configurar ciertas propiedades de ejecución (por ejemplo, donde se encuentra instalado el intérprete). Los botones Save y Load permiten almacenar a archivo (y restaurar luego) la información de preferencias del modelo. Cuando se trata del modelo de Diseño, la extensión del archivo resultante es: .GDP (Genexus Design Preferences). Las preferencias almacenadas en estos archivos sólo pueden ser cargadas en el modelo de diseño, de esa u otras Bases de Conocimiento. Cuando se trata de un modelo de Prototipo o Producción, la extensión del archivo resultante es: .GMP (Genexus Model Preferences). Para modelos de Prototipo / Producción, existe el botón adicional From Model que permite copiar la información en forma directa, desde otro modelo de Prototipo / Producción dentro de la Base de Conocimiento.