Rpido 4GL sistemas, inc.

Documentacin Tcnica Corporativo Normas de codificacin manual Progreso documentacin tcnica Corporativo Normas de codificacin manual Progreso rpido 4GL Systems, Inc. http://www.fast4gl.com/ 220 White Horse Pike Audubon, NJ 08106 Telfono +1 877 327-8445 Fax +1 609 547-7876 Por: Christopher Schreiber Tabla de contenidos Documento Descripcin * Este manual se destina a * Este manual no tiene por objeto * Consideraciones sobre el diseo de base de datos * Definicin * Tablas (o archivos) * Los campos (o columnas) * Los ndices * Integridad Referencial * Convenciones de nomenclatura * General Convenciones de nomenclatura * Procedimientos * Variables * Reproductores *

Marcos * Buffers * Arroyos * Bloques * Ficheros de trabajo y tablas temporales * Referencias externas * Estructura Procedimiento * Esquema general * Programa de cabecera * Variables * Define Otros * Formas * Las rutinas de inicio * Procedimiento de estilo * Sangra * Las declaraciones por lnea * Capitalizacin * Las etiquetas de bloque * Puntuacion * Comentarios * Diccionario formatos y etiquetas * Archivos de inclusin * Si / Entonces / ventas * Declaracin del caso * Sale del programa *

Listado de Nombres de campo * Frase de venta de opciones de formato * Listado de frases Opciones de marco * Palabras clave no usar * Palabras claves que se deben evitar * Abreviaturas * Varios * Marcos * Transacciones * Control de errores * Registro de lectura * Registro de cierre * Portabilidad * Terminales * Nombres * Ficheros de trabajo * Sistemas Operativos * Color * Del sistema operativo * Rendimiento * Tcnicas de codificacin * Multi-Base de datos * Uso de mltiples bases de datos * Transacciones Entendimiento * Descripcin de la Operacin Alcance *

mbito de aplicacin por defecto del bloque * Control de Operaciones * Sub-transacciones * Registro de Seguros y mbito de aplicacin * Registro Esclusas * Registro Alcance * Usando XREF y Listados * Listados * XREF * Documento general Estas son las razones por las cuales el Progreso de codificacin manual de normas se ha creado. Para facilitar la legibilidad del programa Progress y el mantenimiento futuro, es importante identificar y alentar un estilo coherente de codificacin. Este documento no pretende abordar todos los temas posibles porque nuestra experiencia nos ha demostrado que cuanto ms tiempo la norma es el cumplimiento menos que hay. No esperamos que todos estn de acuerdo con las normas contenidas aqu. Sin embargo, estas son las normas y directrices que provienen de aos de la experiencia y no debera perderse de vista, salvo en situaciones de especial. Ningn documento de esta naturaleza siempre se debe escribir en el vaco. Le alentamos infrmenos de las omisiones y los puntos dbiles que podemos hacer los cambios necesarios y ayudar a otros a tener un buen comienzo en sus aplicaciones de Progress. Este manual se destina a

Escenografa y programacin de las normas para los programadores de Progreso Proporcionar directrices para el equipo y los lderes de proyecto durante las revisiones de cdigo

Debe ser una cuestin sencilla de aplicar las normas establecidas aqu para todos los nuevos programas. El objetivo es introducir un estilo de codificacin eficientes que permitan mejorar la legibilidad, mantenimiento y rendimiento. Este manual no pretende

Ensee a nadie cmo programar en el Progreso.

Este documento no sugiere ningn tipo o estilo de SmartObjects y programacin de interfaz grfica de usuario en general. El informe abarca el desarrollo de 4GL cdigo y diccionario de datos solamente. Consideraciones sobre el diseo de base de datos Adecuada base de datos de diseo y convenciones de nomenclatura son probablemente la parte ms importante del proceso de desarrollo de aplicaciones. Para que el cdigo Progreso para ser fcilmente legible y mantenible, amplia previsin debe ir en el diseo y las convenciones de nomenclatura para la propia base de datos. Definicin

Exteriores campos clave tiene el mismo nombre de campo como lo hacen en su mesa original. Duplicar los nombres de campo no debe utilizarse a menos que una clave externa se define. Con el terreno y los nombres de tablas, subraya ("_") guiones ("-") no se debe utilizar para evitar posibles problemas con las implementaciones tercera parte de SQL. ayudar a nivel de campo debe ser ingresado. Mesa y descripciones de los campos debe ser introducido. formatos por defecto de campo se introducen. Siempre debe haber un ndice nico primaria por tabla. El campo que se repite la mayora debera ser el primer componente seguido por la mayora de repetir siguiente campo. Esto hace la bsqueda mucho ms eficaz y ayuda con compresin de ndice (nota: el campo ms la repeticin es aquella cuyo valor cambia por lo menos los ms de varios registros!). No aadir o eliminar campos / tablas / ndices sin llevar a cabo anlisis de impacto para anticipar todos los efectos del cambio.

Mesas (o archivos)

Si se desea la compatibilidad DOS, los nombres de archivo deben ser limitados a 8 caracteres, aunque permite el Progreso 32. Esta restriccin se levant en Construccin versin 6 con la adicin de un carcter de 8 "vertedero" de nombre para el diccionario. Otra razn para mantener los nombres de archivo corto es que almacena los progresos de estos nombres, literalmente, en el R-compilado el cdigo. Por lo tanto, los nombres largos tienen un impacto directo sobre el tamao de los cdigos R. Esto se aplica tambin al campo, variable, y los nombres de workfile.

Utilice archivos de inclusin para la validacin supresin diccionario. Esto permite a los criterios de supresin al ser cambiado, aunque una base de datos puede estar siendo utilizado por otros usuarios. Basta con editar el archivo de inclusin y volver a compilar los procedimientos afectados.

Los campos (o columnas)

Se recomienda que los nombres de campo se limita a 12 caracteres, a pesar de los progresos permite 32. Sea consciente de las limitaciones de utilizar el tipo de datos recid. Durante un volcado de datos utilizando EXPORTACIN, Progreso convierte el recid al valor desconocido (?). Usando almacenados recid s normalmente requiere que el desarrollador escriba volcado de la costumbre y los procedimientos de carga. Para los campos decimales, el nmero de decimales almacenados debe estar igual o superior al nmero de decimales muestra en el formato. El uso de la SIDE-ETIQUETAS causar campos decimales, mediante el formato de carcter ">" a perder la alineacin decimal dependiendo del tamao del nmero que se muestra (incluso si el formato es el mismo tamao). Por lo tanto, el uso de la "z" el formato de caracteres se recomienda. Los formatos para tipos de datos lgicos siempre debe tener el formato positivos a la izquierda y el negativo a la derecha. Un formato de "No / S" puede provocar problemas graves lgica. Para los formatos campo de caracteres, no utilice el "!" y "9" caracteres de formato a menos que un personaje debe ser entrado porque el progreso no permite que un personaje en blanco o no alfabticos utilizando este formato. La longitud de una etiqueta debe limitarse a 14 a fin de que la etiqueta no se truncar cuando se muestran CON COLUMNA 1 o con 2 columnas. Si 3 o 4 columnas se utilizan con frecuencia, la etiqueta no deber ser superior a 12 caracteres. Columna-Las etiquetas deben ser del mismo ancho o menor que el formato del campo para que acte como una etiqueta de "corto" para los informes apretado y pantallas. Si el espacio en pantalla es limitado no pila de etiquetas de las columnas ms de 2 niveles de profundidad.

Evite usar el valor desconocido (?) Como valor inicial, salvo para las fechas. En los campos numricos, los clculos que el valor desconocido suele dar lugar a un resultado desconocido. Ejemplo

Precio Cantidad UPDATE. / * El usuario entra 5 y? * / ASIGNAR total = Cantidad Precio *. / Total * ahora es igual? * /

El valor inicial de un campo lgico siempre debe ser s o no. Considere lo siguiente: Ejemplo Formato: N / G Sello: neto o bruto Inicial: N La "N" en la inicial podra conducir a los no iniciados en la creencia de que el defecto se va por el "Net" cuando en realidad se pondr por defecto a una lgica n o "G" por "bruto".

Obligatorio en general debe estar a YES en los campos donde el valor desconocido podra causar un problema. Esto es para prevenir la corrupcin lgica de los datos descritos en el ejemplo anterior. El progreso no comprueba la sintaxis de una expresin de validacin hasta que un procedimiento es compilado que utiliza esa expresin. Cada vez que un valexp inscrito o modificada, a la salida de la prueba diccionario de la validacin mediante el uso de: Ejemplo INSERTAR cliente. Esto comprobar la sintaxis de todas las expresiones de validacin en el archivo. Asimismo, recuerda que la validacin diccionario slo se aplica a las declaraciones de entrada de datos (UPDATE SET y INMEDIATAFOR).

ndices

El ndice principal debe ser el ndice que se utiliza con mayor frecuencia para recorrer un archivo con una para cada uno, no el ndice utilizado principalmente para acceso aleatorio. Esto har que los datos que sean objeto de dumping en ese orden. Cuando los datos posteriormente se vuelve a cargar en una base de datos nueva, el s recid se asignan secuencialmente a los registros durante la carga. Cuando el ndice principal se construye, que se construir con las referencias a estos recids secuencial. Todos los otros ndices para que se construir con la recids en orden no secuencial. componentes de caracteres ndice debe ser definido como Abreviar en 's' (a menos que el componente no es el ltimo componente del ndice). Esto permitir el uso de un INMEDIATA PARA ENCONTRAR usando la combinacin / sin utilizar el COMIENZA funcin.

No crear ndices que comparten los mismos componentes. Ejemplo ndice ndice-A-B Campo, campo-A Campo B-Campo-B Campo-C ndice-A se considera redundante en este ejemplo, a menos que si ndice-A fue nico e ndice B-no lo era.

Se recomienda que los nombres de ndice se limita a 12 caracteres.

Integridad Referencial La integridad referencial significa asegurar que todos los campos claves externas pueden ser resueltos a una entrada vlida en un tabla asociada. Esto implica que cuando estos campos de clave externa se rellenan un cheque debe ser hecho para asegurar la entrada vlida existe. Si una entrada se borra, un cheque se deben hacer las inscripciones en cualquier tabla que puede utilizar sus campos como claves externas. Si tales relaciones existen, entonces la supresin debera ser rechazada. Normalmente las comprobaciones de integridad referencial se debe poner en su lugar cuando:

es un valor de entrada a un campo de clave externa durante la interaccin del usuario se escribe una entrada a la base de datos una entrada se ha eliminado

La integridad referencial puede realizarse en tres lugares, el diccionario de datos, base de datos activa (crear, buscar, ceder, escritura y borrado) y el cdigo de la aplicacin en s. Utilice el gatillo SUPR para imponer la integridad y la supresin de auditora y el gatillo WRITE para la auditora. Convenciones de nomenclatura A raz de Convenciones de nomenclatura bsica aumentar en gran medida la legibilidad del cdigo. Para facilitar la legibilidad progresos del programa y de mantenimiento futuro, es importante identificar y promover un estilo coherente de codificacin. Este documento no pretende abordar todos los temas posibles porque nuestra experiencia nos ha demostrado que cuanto ms tiempo la norma es el cumplimiento menos que hay.

No esperamos que todos estn de acuerdo con las normas contenidas aqu. Sin embargo, estas son las normas y directrices que vienen de aos de experiencia, no debe ser desviado de, salvo en situaciones especiales. General Convenciones de nomenclatura

Todo progreso palabras reservadas deben ser totalmente en maysculas. Otras entidades de programacin, tales como nombres de variables, se de casos de uso ya sea menor o una mezcla de maysculas y minsculas, como se describe a continuacin para distintos casos concretos. Para los casos no se discute ms adelante, todo en minsculas es la opcin preferida. Los nombres de tablas de campo y comenzar con una letra mayscula, y se usan minsculas para el resto de los nombres sola palabra. Para los nombres de palabras mltiples, cada una de las palabras sern separados por el carcter de subrayado ('_') y cada palabra se iniciar con una letra mayscula.

Procedimientos

Si compatibilidad con las convenciones Progreso se desea, las extensiones de archivo que sigue al nombre se debe utilizar: Extensiones de archivo Nombre . P Procedimiento . I Incluir Archivo . W Ventana

Variables

Para distinguir las variables de los campos de base de datos, se recomienda que un prefijo o sufijo se utilizar para establecer el nombre real fuera. Esto hace que sea mucho ms fcil para el programador de mantenimiento para realizar un seguimiento variables a travs de una cadena de procedimientos. Si la variable se define como un campo, el nombre del campo debe estar contenida en el nombre de variable. Variable de nomenclatura vDate DEFINE VARIABLE COMO FECHA NO-DESHACER. DEFINE VARIABLE vItem_no Item.Item_no COMO NO-UNDO. DEFINE entrada de parmetros ipUpdate tan lgica NO-UNDO. DEFINE VARIABLE sGLCode COMPARTIDA COMO PERSONAJE NO-UNDO. DEFINE VARIABLE GLOBAL COMPARTIDA gsCompany COMO ENTERO NO-UNDO.

Debido a que la versin 6 permite la construccin db.file.field, se recomienda que los nombres de base de datos y archivo / amortiguadores ser distintos nombres para evitar confusin sobre database.file y file.field.

Reproductores

Un nmero de otros widgets estn disponibles en V7 y V8. Las convenciones de nomenclatura de estas deben ser las mismas que para el campo y nombres de archivo pero con un prefijo que indica qu tipo de objeto se refiere. Estos son los siguientes: Widget de nomenclatura br Examinar qu consulta cb cuadros combinados ed Caja Editor Activar Caja tg Radio Set rs sl Lista de seleccin Ejemplos Widget CONSULTA PARA DEFINIR quOffice_Header Office_Header. DEFINE brOffice_Header BUSCAR BSQUEDA quOffice_Header PANTALLA Office_Header.Office_Number Office_Header.Office_Type Con el ttulo "Seleccione una Oficina" 8 ABAJO. cbHist_Date DEFINE variable como formato de fecha "99/99/9999" VER-AS-BOX COMBO LISTA DE TEMAS-04/07/1066, 20/01/1966/27/10/1991.

Marcos

Al igual que con las variables, nombres de los marcos tambin debe tener un prefijo o sufijo a prenderlos. Adems, el marco debe ser identificado por tipo (locales o compartidos). En conversaciones con varias pantallas, el marco tambin puede necesitar estar contados. Marco de nomenclatura DEFINE MARCO fMain.

Buffers

Almacenadores intermediarios tambin deben tener un sufijo / prefijo que se identifique como compartidos o locales. El nombre del archivo base de datos que representa el bfer debe estar contenido en el nombre. Buffer de nomenclatura DEFINE BUFFER bCustomer para el cliente.

Arroyos

Corrientes debera tener un sufijo o prefijo. Corriente de nomenclatura DEFINE sReport STREAM.

Bloques

etiquetas de bloque son para estar en una lnea separada por encima del bloque de instrucciones. Bloque etiquetas MAIN-LOOP: REPEAT: PANTALLA Customer.Name. END. / * MAIN-LOOP: * /

etiquetas de bloque debe tener un sufijo o prefijo y dar algunas indicaciones sobre el nivel de anidamiento de la manzana se est etiquetando. Los nombres de etiqueta de bloque MAIN-LOOP: REPEAT: / * La interaccin del usuario / TRANS-LOOP: / * * Actualizacin de transacciones / END. / * TRANS-LOOP: * / END. / * MAIN-LOOP: * /

bloques con etiqueta debe tener la etiqueta de bloque como un comentario al lado de la instruccin END para el bloque, incluir los dos puntos en la etiqueta de bloque para una rpida / fcil acceso a la inicial y final del bloque. Bloque Comentarios Label MAIN-LOOP: HACER: / * Bloque de cdigo aqu * / END. / * MAIN-LOOP: * /

El progreso permite etiquetas duplicadas bloque en el mismo acto, sin embargo, esta prctica no se recomienda debido a la posibilidad de confusin.

Ficheros de trabajo y Temp Tablas

Para distinguir ficheros de trabajo de los campos de base de datos, un prefijo se debe utilizar. Si el workfile representa un archivo de diccionario, el nombre workfile debe contener el nombre del archivo diccionario. Esto har que sea ms fcil localizar al realizar bsquedas de texto. Workfile y la tabla de nombres Temp DEFINE ttCustomer TEMP-CUADRO clientes, como el. DEFINE COMO wfCustomer WORKFILE cliente.

Cuando un ndice se compone de un solo campo, el nombre del ndice debe ser el mismo que el campo. Cuando un ndice tiene ms de un componente, el ndice debera tratar de parafrasear a los campos utilizados en el ndice. Nombramiento de Indices Nombre del ndice: cliente-ord ndice Cust con-num y Ord campos no.

Referencias externas

Cuando la produccin se dirige a Progreso un archivo ASCII, las convenciones de nomenclatura se aplicarn las siguientes. Por razones de portabilidad, el nombre del archivo no debe superar los 8 caracteres con un sufijo de 3 caracteres. Para evitar colisiones con otros usuarios que tambin puede ser la escritura de archivos ASCII en el disco, una de las siguientes convenciones se puede utilizar: Escribe al directorio home del usuario o especialmente designados directorio temporal. Realiza el nombre del archivo nico. Por lo general, la eTime funcin con un desempate como identificador de usuario es suficiente para evitar conflictos de nombres. Utilice un archivo. D sufijo para los ficheros que contienen datos EXPORTACIN ed.

Procedimiento Estructura Siguiendo estas pautas de procedimiento Estructura permitir ser capaz de rastrear el flujo del programa con mayor facilidad. Esquema general El esquema general o el flujo de un programa debe ser el siguiente: Esquema general

1. 2. 3. 4. 5. 6.

Encabezamiento Variables Otras definiciones Formularios Consejo de Procedimiento Punto de salida

Programa de cabecera El encabezamiento de cada programa se organiza de la siguiente: Programa de cabecera 1. 2. 3. 4. 5. 6. 7. 8. 9. Nombre del programa Nombre de la aplicacin / mdulo Ubicacin del Programa / Directorio Aviso de Copyright Historia Modificacin / Revisiones / Iniciales / Fecha Razones para cada cambio Incluir lista de archivos Archivos de leer (entrada) Archivos por escrito (de salida)

10. Objetivo y descripcin general del programa Variables Variables deben ser dispuestos en el orden siguiente: Variables Todo el sistema incluyen las variables de archivos. Aplicaciones especficas incluyen variables de archivo. nuevas global compartida nuevas para compartir compartido local Las variables se presentan en orden alfabtico para hacer ms fcil localizarlos.

Todas las variables, ficheros de trabajo, y definir los parmetros deben ser definidos como no-deshacer. Todas las excepciones deben ser comentados para evitar cambios futuros que vayan a causar problemas. Las variables siempre se define como file.field nombre-siempre que sea apropiado para la auto-documentacin y facilidad de mantenimiento. Una posible desventaja es que, al igual que una sesin requiere estar conectado a la base apropiada. Las variables no tienen el mismo nombre como un campo de base de datos oa una base de datos (versin 6) para mayor claridad. Todos compartan NUEVO / variables compartidas deben ser almacenados en los archivos de inclusin que pasa NUEVO como parmetro en el procedimiento de los que inicialmente definido. Esto facilita el mantenimiento y evitar problemas con los conflictos de tipo de datos, NO-UNDO, ALCANCE, etc

Cuando las variables que definen todas las opciones de definicin debe ajustarse para mejorar la legibilidad. Variable de alineacin DEFINE VARIABLE vNombre AS carcter de formato "x (10)" LABEL "Nombre" NO UNDO. DEFINE VARIABLE vKey AS INTEGER FORMATO "zz9" NOUNDO.

N variables deben ser definidas en una declaracin que no sea una declaracin DEFINE. El progreso permite la definicin de variables en la pantalla, UPDATE, la forma y los datos de otras declaraciones de la manipulacin, pero son difciles de encontrar y mantener cuando DEFINE d de esta manera.

Define Otros Otras definiciones se describen en el siguiente orden: Define Otros 1. 2. 3. 4. 5. 6. nueva corriente global compartida corriente compartida nueva corriente compartida corriente bfer compartida nueva compartida de amortiguamiento

7. 8. 9.

buffer workfile compartida nueva compartida workfile

10. workfile 11. nuevo marco compartido 12. estructura compartida 13. parmetro de entrada 14. parmetro de salida 15. parmetro de entrada-salida Formularios Los formularios sern las definiciones que figuran en el orden siguiente: Formularios 1. 2. 3. 4.

Nuevo marco para compartir archivos incluyen las formas marco compartidas incluyen formas de archivo Incluir archivo de formularios formas locales Todas las opciones Frase MARCO asociados con un marco debe aparecer slo en la declaracin FORMA para facilitar el mantenimiento. Todas las formas descritas en un programa se debe dar nombres explcitos marco. Esto es particularmente importante cuando se forman s se colocan al inicio de un procedimiento, alcance a la cuadra procedimiento.

Las rutinas de inicio

Cualquier archivo de inclusin rutinas de inicio, como las partidas de pantalla y los controles de seguridad debe aparecer juntos. Variable de inicializacin tambin debera hacerse en esta seccin. Punto de salida: Todos los procedimientos deben tener un punto de salida comn. Normalmente es una instruccin RETURN en la ltima lnea del procedimiento. Un RETORNO cualquier otra parte del procedimiento es similar a una declaracin GOTO en otro idioma. La nica diferencia es que el regreso slo puede volver al procedimiento de llamada.

Este punto de salida tambin debe ser utilizado para ocultar cualquier marco que no es necesario que sea visible en la de volver al procedimiento de llamada e inicializar las variables compartidas que deben ser.

Procedimiento Estilo Procedimiento Estilo es nica para cada programador. Sin embargo, a raz de estas sugerencias permitir a los programas que se escribe para ser ms fcil de mantener. Sangra

indentacin recomendada es de 3 espacios. Cuando el nivel de bloque de anidamiento llega al punto donde las lneas se estn "rotos" antes de tiempo, 2 sangra espacio est permitido, aunque esto puede ser un sntoma de diseo del programa pobres. Todas las declaraciones contenidas dentro de un bloque debe tener una sangra: Ejemplo sangra MAIN-BLOCK: Para cada cliente: PANTALLA cliente. ORDEN-BLOCK: Para cada orden WHERE Order.Cust_Num = Customer.Cust_Num NO BLOQUEAR: Orden de presentacin. END. / * ORDEN-BLOCK: * / END. / * MAIN-BLOCK: * /

FIN declaraciones siempre se alinear con la declaracin de bloques que estn terminando.

Las declaraciones por lnea

Slo una declaracin por lnea es permitido para mejorar la legibilidad. Una declaracin no podr ser prorrogado por el uso de la tilde (~).

Capitalizacin

Todo el cdigo ser en minsculas, con excepcin de las etiquetas de bloque y el texto dentro de un comentario.

Bloque etiquetas

Grandes bloques PARA REPETIR y cada uno debe ir precedida de una etiqueta de bloque que se describe la funcin del bloque.

La etiqueta debe estar en una lnea por s mismo por encima del encabezado de bloque (vase el ejemplo anterior). bloques NO slo requieren etiquetas cuando se usan para otros fines que no sean declaraciones que agrupa como la definicin de un marco nuevo o cambiar el alcance de transaccin, o cuando son ms de 10-12 lneas. Cualquier bloque que est sujeta a una siguiente, deje, o declaracin UNDO debe tener una etiqueta de bloque. El siguiente, deje, o una declaracin explcita referencia UNDO esa etiqueta.

Puntuacion

Todas las declaraciones proceso terminar con perodos salvo la etiqueta de bloque y bloque de cabeceras (REPEAT / DE / DO), que se terminan con dos puntos.

Comentarios

Todas las cabeceras de bloque (PARA CADA / REPEAT) debe ir precedido de un comentario que describe el propsito del bloque, especialmente si ese bloque es un bloque de transaccin. Todas las declaraciones END para los bloques se deben seguir con un comentario de que "coincide con" el fin de la declaracin de encabezado de bloque. Las nicas excepciones seran los bloques que contienen algunas declaraciones muy Ejemplo Comentarios / * Actualizacin de Documentos del cliente * / CUST-UPDATE-BLOCK: REPEAT: INMEDIATA PARA Customer.Cust_Num. ENCONTRAR cliente USO Customer.Cust_Num. UPDATE cliente CON COLUMNA 1. END. / * CLIENTE-UPDATE-BLOCK: * /

comentarios de varias lneas deben estar en la forma: Multi-Line Ejemplo Comentarios / * Esta lnea es la primera lnea de comentarios ** Y esta es la segunda lnea * /

comentarios de una sola lnea debe estar en la forma: Ejemplo de lnea nica Comentarios

/ * Esta es una lnea de un comentario * /

No hay necesidad de comentar la declaracin END: No hay necesidad de enviar algn comentario de la END De ser cierto-condicin THEN HACER: MENSAJE "True". END.

Diccionario formatos y etiquetas

Etiquetas, formatos, validacin y la ayuda del diccionario se debe utilizar en lugar de reemplazar en el procedimiento. Cuando imperiosa etiquetas diccionario, hacerlo en el formulario o declaracin MARCO definir si una se utiliza para definir el marco. Para las variables especificar ETIQUETA y formato en el FORMULARIO DE DEFINIR o declaracin en lugar de en el manejo de datos tales como declaraciones mostrar y actualizar. Use LABEL when defining side-labels and COLUMN-LABEL when defining column labels. Keep the width of the COLUMN-LABEL the same as the FORMAT . Column-Label Example Pasado Date Last Date Invoiced Last Date Invoiced Invoiced -------- ------------------ --------12/31/99 12/31/99 12/31/99 In this example, Last!Date!Invoiced may be the best for the convservation of horizontial space at the cost of one line of vertical space.

Archivos de inclusin

When overriding dictionary labels, do so on the FORM or DEFINE FRAME statement if one is being used to define the frame. Use system include files whenever possible. System include files used across multiple applications are located in the "include" directory. Application specific include files are located in that application's subdirectory (eg ar/).

Named parameters rather than positional parameters will be used whenever parameters need to be passed to an include file. It is recommended that include files not be nested more than 3 levels deep as debugging can be difficult. Also the "explosion" of the include files seen when using the COMPILE / LISTING option makes the code difficult to read. Include file coding style, simple includes: Simple Include Files {std-var.i}

Include file coding style, simple parameters: Simple Parameter Include Files {std-var.i &var-type = "NEW"}

Include file coding style, multiple parameters: Parmetro de mltiples archivos de inclusin (Lookup.i Y de nombre de archivo = Cliente Y el chass-atr = "NO-BOX 2 columnas" Customer.Cust_Num & key = )

Incluir archivos no deben terminar un bloque empez fuera del archivo de inclusin. Por el contrario, un archivo de inclusin no debe comenzar un bloque que termina fuera del archivo de inclusin. No codificar un nombre de ruta en el archivo de incluir una referencia. PROPATH se puede utilizar (y ajusta dinmicamente segn sea necesario) para cambiar los directorios en tiempo de compilacin. No ponga observaciones en el plazo de llaves incluyen una llamada de archivo, como el compilador tiende a confundirse. No use los comentarios dentro de un archivo de incluir una referencia (Lookup.i / * Esto puede volar! * / & Param = "valor" )

Si / Entonces / ventas

El uso de NO debe ser evitado. Buena prueba de estilo dicta una condicin positiva siempre que sea posible. De acuerdo a utilizarse al analizar las funciones lgicas y variables. Mezcla de AND y OR condiciones se debe evitar, pero si se utiliza el orden de evaluacin deben ser explcitamente indicado a travs del uso de parntesis. Ponga cada condicin en una lnea separada la alineacin y / o s verticalmente. Mezclados y / o Ejemplo Condiciones Si es verdad-Y cond1 -Y cierto cond2 (True-O cond3 verdadero-cond4) ENTONCES

Para un grupo de condiciones relacionadas con AND, la condicin ms probable (s) debe ser probada por primera vez. Para un grupo de condiciones conectadas por OR, la condicin ms probable (s) debe ser probada por primera vez.

Every branch of an IF / THEN / ELSE will use a DO block to enclose the code even if there is only one statement. The cost is a slight increase in R-code size. This will prevent errors if other statements are added to the branch later on. Example of when to use DO: END. with an IF Statement IF true-condition THEN {include.i}. If this include file originally had only one statement and more were added later, the new statement would not be conditionally executed. Instead you should use: IF true-condition THEN HACER: {include.i} END.

The only exception would be a nested IF / THEN / ELSE when there was only one possible statement. Example of when not to use DO: END. with an IF Statement Si la seleccin = "A" luego en Ejecutar add.p. ELSE Si la seleccin = "C" ENTONCES change.p RUN. ELSE Si la seleccin = "D" luego en Ejecutar delete.p.

else debe aparecer en lneas independientes, en consonancia con las declaraciones de IF para que se apliquen. Para los ensayos en recintos, alinee el s OR y AND s. Compuesto Y / O Ejemplo SI condicin AND vBegDate> Y Order.Order_Date vEndDate <Order.Order_Date ENTONCES HACER: / Declaraciones * * / END.

Al probar los campos lgicos o variables, no utilice TRUE, FALSE, s, y no para realizar comparaciones debido a la reduccin del rendimiento y de mayor cdigo R. Use the Progress CASE statement (V7) when ever possible. If it is necessary to use nested IF statements, use the following constructs: Multiple IF / THEN / ELSE Example IF condition AND vBegDate > Order.Order_Date AND vEndDate < Order.Order_Date THEN HACER: /* Statements */ END. ELSE IF NOT (condition) THEN HACER: /* Statements */ END.

The use of "null" THEN s and ELSE s is not allowed. Null THEN / ELSE Example IF condition THEN . ELSE. This code does compile and illustrates what a "null" THEN or ELSE is.

Case Statement

In Version 7 Progress use the CASE statement, instead of nested IF / THEN / ELSE statements. Example of the CASE statement

CASE selection WHEN "A" THEN RUN add.p. WHEN "C" THEN RUN change.p. WHEN "D" THEN RUN delete.p. OTHERWISE MESSAGE "Incorrect Selection.". FIN DEL CASO. Program Exits

All procedures should have a single exit point. The last statement of every program should be a RETURN and this should be the only RETURN used in a program. To "goto" a RETURN from within the program, use the LEAVE statement. Example of Program Exits PRINCIPALES: REPEAT: PROMPT-FOR Customer.Cust_Num. FIND Customer USING Customer.Cust_Num NO-ERROR. IF NOT(AVAILABLE(Customer)) THEN LEAVE MAIN. UPDATE Customer WITH 2 COLUMNS. END. /* MAIN */ RETURN.

Listing Field Names

All field names should be "qualified" and typed in as filename.field-name. If common file names are used between multiple databases, the convention dbname.filename.fieldname should be used. Lists of field names in a DISPLAY, UPDATE, FORM, etc. should be shown as follows: All names can fit all on one line: Example of Fields on one line DISPLAY Customer.Cust_Num Customer.Name.

Multi-line listing: One field per line indented 3 spaces. Also if the FRAME Phrase is used, it will be aligned with the fields/variables. Example of Fields on multiple lines UPDATE Customer.Cust_Num Customer.Name Cliente.Direccion

Customer.Phone CON MARCO fCustFrame.

Cuando se muestra un subconjunto de una matriz, utilice la siguiente notacin: Ejemplo de uso de una matriz PANTALLA array [1 DE 5]. Este mtodo es ms fcil de leer y mantener que enumerar a cada elemento del arreglo individual.

Frase de venta de opciones de formato

Cuando el formato de las opciones de frases se utilizan, deben estar alineados verticalmente u horizontalmente. Ejemplo de las opciones de Formato Frase UPDATE Customer.Name AYUDA "Introducir el nombre de los clientes ' VALIDAR (NE Customer.Name "," Nombre de cliente debe introducir ") Customer.Contact A 20 AYUDA "Enter Contacto del cliente". UPDATE vStartDate AL 10 DE AYUDA "Enter Fecha de inicio" vEndDate AT 50 AYUDA "Enter Fecha de finalizacin" UPDATE Customer.Name AYUDA "Introducir el nombre de los clientes ' VALIDAR (NE Customer.Name "," Error ") A 20 Customer.Contact AYUDA "Enter Contacto del cliente".

Listado de frases Opciones de marco de

Organizar opciones de marco de expresin de manera que se evite la colocacin de dos nmeros enteros juntos por las diferentes opciones. Ejemplo de las opciones que se deben evitar frases marco UPDATE Customer.Name Customer.Phone CON RETENER 1 8 2 2 ABAJO ROW COLUMNAS.

Ejemplo de las opciones de frases marco preferente UPDATE Customer.Name Customer.Phone Con 2 columnas 8 ABAJO ROW 2 RETENER 1. Palabras clave no usar

instruccin STOP: til solo para probar. USE-INDEX option: Essentially hard-codes an index name into a procedure. Don't use unless knowledge of data distribution shows that Progress' automatic index selection will be incorrect. Should never be used in Version 7 Progress.

Keywords to Avoid

OF : OF makes code easier to read, but hides the name of the field(s) being used to relate the files together. Ok to use when there are no further qualifications necessary for record selection. Do not use OF and WHERE together. ENTERED function: The ENTERED flag is easily cleared by an UNDO , RETRY and could lead to incorrect results. RELEASE statement: Use of this statement within a TRANSACTION might indicate a lack of understanding record and/or transaction scope. RELEASE cannot release SHARE-LOCK or EXCLUSIVE-LOCKs within a transaction. OR operator: Use in a WHERE clause can negate the efficient use of an index.

Las abreviaturas

The abbreviation of variables, file and field names is not allowed. The following keywords should not be abbreviated, because the minimum allowed abbreviation is too short: Keywords to NOT Abbreviate ACCUMULATE DISPONIBLE AVERAGE ALL COLORS (BLACK, BLUE, CYAN, ETC.) BLINK FECHA LUZ NO-VALIDATE PROMPT-FOR RECID

SUB-AVERAGE TRANSACCIN DESTACAN

The following keywords may be abbreviated, but not as much as Progress allows: Las palabras clave que pueden ser abreviadas Palabras ANIMALES CARCTER CHAR DECIMAL diciembre DESCENDING DESCIENDA ENTERO INT De registro lgico

Todo progreso compatible con otros abreviaturas se admiten.

Miscelneo

Duro de codificacin de los valores en cualquier programa no se recomienda con las siguientes excepciones: los parmetros pasados a un archivo de inclusin y constantes que no cambia (por ejemplo, 12 meses en un ao). No hardcode keylabels en un procedimiento. Ejemplo de codificacin Keylabels MENSAJE "Introducir datos y Pulse" + KBLABEL ("GO").

S largo mensaje que no caben en una lnea debe ser codificada: Ejemplo de mensajes largos MENSAJE "Este es un mensaje muy largo que no cabe en una" "Lnea en el cdigo.".

Nota en el ejemplo anterior que la cadena de mensaje se delimita con un espacio en blanco en cada extremo. Esta sugerencia tambin se refiere al TTULO s. Ejemplo de los ttulos FORMA Customer.Cust_Num Customer.Name Con el ttulo "La informacin de los clientes 'centrado.

Algebraico lgico operadores estilo se prefieren sobre el estilo FORTRAN. De cualquier estilo es aceptable.

Ejemplo de Operadores En lugar preferente de a> <b bis NE a <= b bis LE a> b = GE bis un GT bis b> ba una LT <b a = b bis EQ

Cuando utilice DO MIENTRAS / REPEAT los bucles while, siempre de ensayo de un "menor que" o "mayor que" enfermedad en lugar de "igual a". Esto evita que un bucle infinito si la igualdad "a la" condicin nunca se cumple. Ejemplo de un control aceptable TEST-BLOCK: NO bien esto es cierto: / * Declaraciones * / SI <= 0 THEN vCounter PRUEBA DE LICENCIA-Block. END. / * TEST-BLOCK * / Ejemplo de un control Inaceptable TEST-BLOCK: NO bien esto es cierto: / * Declaraciones * / SI vCounter = 0 THEN PRUEBA DE LICENCIA-Block. END. / * TEST-BLOCK * /

carcter de campo TRIM sensibles a espacios a la izquierda (es decir, ordenar campos). Los campos en un comunicado FORMA debe aparecer verticalmente uno por lnea para facilitar su mantenimiento. Ejemplo de un Formulario de Declaracin FORMA Customer.Cust_Num Customer.Name Customer.Phone CENTRADO CON LNEA 2. Ejemplo de una forma inaceptable Declaracin

Customer.Cust_Num FORMA Customer.Name Customer.Phone CON CENTRADO. Marcos

Los marcos deben ser normalizados mediante el cuadro de defecto o sin caja. Marcos usado para la salida impresa debe usar NO-BOX para recuperar la lnea en blanco (y columnas) que asigna el Progreso de la "invisible" cuadro de grficos en la parte superior del marco. Para anchos de marco normalizado de los informes, el uso anchos estndar que contienen los caracteres por pulgada utiliza normalmente en la impresora: Marco Anchos 10 IPC: 75/125 12 IPC: 90/140 etctera

Evite anchos que superan 132 columnas sobre todo porque lo que compromete la capacidad para que un usuario enve un informe amplio a sus terminales (mediante la instruccin TERMINAL) sin envoltorio. Adems, significa que no hay necesidad de apoyar condensada / impresin comprimido para una variedad potencialmente de impresoras. Para aprovechar al mximo el papel, pero todava dejan un margen adecuado, PGINA uso talla 60.

Transacciones

Bloque de cabeceras que definen una transaccin explcitamente debe utilizar la palabra clave de transaccin para auto-documentacin. Esto permitir que el compilador de captura de transacciones posibles errores.

Control de errores

A Progress error (eg entering a duplicate key into a unique index) should not send the user back to the beginning of the block which is the Progress default ( UNDO , RETRY ). Instead, more localized DO ON ERROR blocks along with NEXT-PROMPT should be used to keep the cursor on the field where the error occurred. The UNDO statement should never be used without a RETRY , NEXT , LEAVE or RETURN even though Progress allows it. Always follow the UNDO with the appropriate action ( NEXT , LEAVE , RETRY , RETURN ) and a label if appropriate. Although Progress allows the use of RETURN , as stated earlier this is to be avoided.

Record Reading

Always use WHERE instead of OF so that whoever is looking at the code always knows which fields are being used to join files, unless there are no further conditions necessary for record selection. Do not use OF and WHERE together. Example of Acceptable Record Reading ORDER-BLOCK: FOR EACH Order WHERE Order.Cust_Num = "1000" NO-LOCK: PANTALLA Order.Cust_Num Order.Ord_Num. ITEM-BLOCK: FOR EACH Order_Line OF Order NO-LOCK: PANTALLA Order_Line.Order_Line_Num Order_Line.Item_Num. END. /* ITEM-BLOCK: */ END. /* ORDER-BLOCK: */ Example of Unacceptable Record Reading ORDEN-BLOCK: Para cada orden WHERE Order.Cust_Num = "1000" NO BLOQUEAR: PANTALLA Order.Cust_Num Order.Ord_Num. ITEM-BLOCK: PARA CADA Order_Line De orden donde Order_Line.Order_Qty> 0 NO BLOQUEAR: PANTALLA Order_Line.Order_Line_Num Order_Line.Item_Num. END. / * PUNTO-BLOCK: * / END. / * ORDEN-BLOCK: * /

USO se puede utilizar en vez de cuando, debido USO se especifica la clave utilizada. Para un buen estilo el lado izquierdo de la comparacin en una clusula WHERE siempre ser el campo utilizado para recuperar el registro. Ejemplo de una clusula where ENCONTRAR DONDE Customer.Cust_Num cliente = 10. En lugar de: ENCONTRAR DONDE cliente = 10 Customer.Cust_Num.

Si el nivel de transaccin y estructura de soporte que, todos los registros relacionados se deben encontrar en una sola instruccin FOR EACH. Ejemplo de un compuesto para cada declaracin PARA CADA cliente NO-LOCK, Cada Orden de NO-LOCK WHERE Order.Cust_Num = Customer.Cust_Num, CADA Order_Line NO-LOCK WHERE Order_Line.Order_Num = Order.Ord_Num: END.

Cuando hay varias condiciones en la clusula WHERE, utiliza el siguiente formulario (tenga en cuenta la sangra): Ejemplo de mltiples Condicin WHERE clusula Ejemplo 1: PARA CADA cliente WHERE Customer.Cust_Num> 10 y Customer.Cust_Num <100 y Customer.State = "MA" NO BLOQUEAR: END. Ejemplo 2: NO PARA CADA cliente-LOCK WHERE Customer.Cust_Num> 10 y Customer.Cust_Num <100 y Customer.State = "MA", Cada Orden de NO-LOCK WHERE Y = Order.Cust_Num Customer.Cust_Num

Order.Order_Num> 100 BREAK POR Order.Order_Date POR Customer.Name: END.

Cuando se recupera uno a uno los registros relacin en una instruccin FOR, la CADA se debe utilizar en caso de que el registro no se encuentra. Si hay una posibilidad de que un registro puede faltar, debe ser atrapado usando FIND / NO-ERROR y la funcin DISPONIBLE. Cuando un INMEDIATA PARA va seguido de un buscar, usar NOERROR en la instruccin FIND a menos que desee utilizar la opcin predeterminada Progreso control de errores (un mensaje de error seguido de UNDO, RETRY del UNDO bloque ms cercano). FIND / NO-ERROR siempre ser seguida de una prueba con la funcin DISPONIBLE. FIND / NO-WAIT siempre ser seguida de una prueba con la funcin BLOQUEADO.

El orden de las comparaciones en una clusula WHERE debe seguir esta jerarqua: Orden de comparaciones en una clusula WHERE

1.

Los campos del ndice utilizado por el FIND / FOR EACH. Las comparaciones deben ser en el mismo orden que los campos se producen en el ndice. 2. Los campos de los ndices no se utilizan por la FIND / PARA CADA. 3. 4. 5.

No reajustables campos. Variables. Expresiones. Do not use a FIND statement on a non-unique index or when all of the components of a unique index are not supplied. FIND is designed to retrieve a single record based upon unique index information. Use FIND FIRST / NEXT / PREY / LAST for all other situations. Do not use a FOR block when retrieving a single record based upon a one-to-one relationship. Do Not Use a Join for a one-to-one Relationship FOR EACH Order_Line: DISPLAY Order_Line.

FOR EACH Item OF Order_Line: DISPLAY Item. END. END. The use of FOR EACH when retrieving the item misleads one into thinking that the order-line: item relationship is one-to-many rather than one-to-one.

When testing logical fields or variables in a WHERE clause, explicitly test against the implicit true or false value of the field for R-code and performance reasons.

Registro de bloqueo

Use NO-LOCK siempre que el estado de la informacin no es importante (por ejemplo, la mayora de las investigaciones e informes) para reducir la contencin y mejorar el rendimiento. Cuando ello sea razonablemente seguro de que un usuario se actualiza un registro existente y que el registro no causar bloqueo contencin, leer el acta EXCLUSIVA-LOCK. Esto reducir las posibilidades de abrazo mortal, as como ofrecer una pequea ganancia de rendimiento. SHARE-LOCK nunca debe ser usado. Con SHARE-LOCK siempre existe la posibilidad de que mortales abrazos, o callejn sin salida, podran ocurrir. Siempre explcitamente el estado de bloqueo. El uso de la opcin de inicio-NL es prohibido.

Portabilidad Dado que los programas El progreso puede ser desplegado en muchas plataformas diferentes, es importante mantener algunos de estos problemas la portabilidad en mente cuando se est programando. Terminales

Debido a que existe la posibilidad de que el progreso puede ser ejecutado utilizando los terminales con un nmero variable de lneas disponibles (25 para DOS, 24 para la mayora de terminales ASCII), utilice las siguientes funciones para el clculo de las lneas disponibles y aprovechar al mximo el espacio disponible en pantalla. Gran fiabilidad y Verificacin LNEAS DE PANTALLAMARCO-DOWN MARCO y el resto del MARCO-LINE

En el marco de la frase: expresin ABAJO ROW expresin

La misma situacin existe con el espacio y no tener el espacio de toma de terminales. Para aprovechar al mximo el espacio disponible en la pantalla y seguir manteniendo la portabilidad, se recomienda lo siguiente: Todos los marcos con la entrada de datos o el uso de atributos de color se utilizar ATTR-espacio en el marco de frases de ese marco. Todos los procedimientos sern compilados con la opcin-ATTR-ESPACIO opcin NO.

Nombres

If DOS compatibility is needed, the following items will be limited to 8 characters in length. DOS Limitations Nombres de archivo Procedure Names Include File Names

Name suffixes are limited to 3 characters. The period "." may not be used in the body of the name, but only to separate the procedure or include name from the suffix. All procedure and include file names should be in lower case.

Workfiles

On 640K DOS machines, there is very little memory available to allocate to local buffer space (the -l parameter). The 64K barrier on local buffer size on DOS machines affects portability when large numbers of workfile records might be created. Because of this, the use of workfiles is discouraged unless both of the following conditions are met: The number of workfile records created will remain static or not exceed a predetermined "high water mark". The workfile records will not be increased in size during execution of the procedure.

Sistema Operativo

Use the OPSYS function to shield operating system calls. Checking for the Operating System Example

CASE OPSYS WHEN "unix" THEN UNIX. WHEN "msdos" THEN DOS. WHEN "vms" THEN VMS. WHEN "btos" THEN BTOS. WHEN "os2" THEN OS2. WHEN "os400" THEN OS400. WHEN "nt" THEN NT. EN OTRO LUGAR MESSAGE "Unknown Operating System:" OPSYS. FIN DEL CASO. Color

Utilice el valor de color (color variable) en todas las frases marco. An installation that starts with monochrome monitors and then migrates to color can easily take advantage of the color if the coding is done in this style.

Operating System Specific

OUTPUT THRU is very useful and powerful, but is not supported on all Progress platforms. AUTO-RETURN should never be used. When a transaction completes, the user should be informed with a message that the transaction has successfully finished and been committed to the database. Warning messages should be preceded with "WARNING:" Error messages should be preceded with "ERROR:". This includes the valmsg in the dictionary as well as the second argument of the VALIDATE format phrase option. All error messages should be accompanied by an audible BELL . Help messages should be preceded with "Enter". Because the END-ERROR key has two possible actions that might be taken, the ambiguous nature of the key can confuse users.

Rendimiento Although Performance is often not the first priority when programming, it is important to keep some of these basic concepts in mind. Coding Techniques

CAN-FIND is more efficient than FIND because CAN-FIND only looks at the index (usually 1 I/O operation) where FIND retrieves the entire record (minimum of 2 I/Os).

For the display of constant data, the construct: Example of Displaying Constant Data FORMA "This is a constant string" WITH FRAME fTest. VIEW FRAME fTest. /* This is more efficient then: */ DISPLAY "This is a constant string".

When there are more than 1 assignments next to each other, use the ASSIGN statement. Example of the Assign Statement ASIGNAR vVar1 = vVar2 vVar3 = vVar4. /* This is more efficient, and produces smaller R-code then ** the following: */ vVar1 = vVar2. vVar3 = vVar4.

Minimize RUN statements (use include files if possible) and use a fully qualified path name with a RUN statement. Only qualify the path from the top directory of the application to allow flexibility in a development/production environment. Minimize calls to the operating system. When sharing a record between programs, use SHARED BUFFER s instead of passing a RECID with a shared variable. Exception: when reading the record NO-LOCK in the calling procedure (no transaction active) and re-reading the record EXCLUSIVE-LOCK in the sub-procedure to limit the transaction to the subprocedure. When a variable is changed in a transaction or sub-transaction that variable and all other variables in that procedure are written to the local before image (.lbi) file. To reduce the overhead of this journaling, define variables as NO-UNDO when: When is use NO-UNDO Variables

1. The variable represents a constant that will never change.

2. The variable is always initialized before it is used. 3. UNDO processing serves no useful purpose. 4. The variable is changed in a loop that an error may not occur in.

Reading a record NO-LOCK eliminates the need for Progress to check the locking table for a slight performance gain. Read records EXCLUSIVE-LOCK instead of the default which is a SHARE-LOCK upgraded to an EXCLUSIVE-LOCK when the record is updated. For multiple string comparisons, use CAN-DO , LOOKUP or INDEX versus multiple comparisons OR ed together. Examples of CAN-DO and LOOKUP CAN-DO("PA,NJ,DE",vState) /* This is the most effiecent */ LOOKUP(vState,"PA,NJ,DE") <> 0 vState = "PA" OR vState = "NJ" OR vState = "DE" /* Do Not Use */

Reduce start/stop of transactions in a tight loop (eg batch creation of a large number of records). Example of Reducing Transactions INPUT FROM datafile. REPEAT TRANSACTION: REPEAT vCounter = 1 TO 100: CREATE Customer. IMPORT Customer. END. END. /* Is more efficient then: */ INPUT FROM datafile. REPEAT: CREATE Customer. IMPORT Customer. END.

When loading data into a database, use the NO-ECHO option on the INPUT FROM statement.

When loading data into the database, use IMPORT (Version 6 and later) rather than SET or UPDATE . Only use WORKFILE s for a fixed number of static records Creating WORKFILE records in an unrestricted way can crash the user by running out of local buffer (-l) memory. Also re-sizing existing WORKFILE records is a potential performance inhibitor.

Multi-Database Working in a Multiple Database environment can bring up some more issues to be concerned about. Using Multiple Databases

Do not use the Progress Auto-Connect feature. It can cause unexpected pauses in a procedure as the connection is initiated. For modularity, put ail CONNECT logic at the start of the user's session. Use NO-ERROR on the CONNECT and test to see if the connection was established using the CONNECTED function. Use one CONNECT statement per database. If a multi-database CONNECT fails, all subsequent connections will not be established.

Understanding Transactions Transactions, and how Progress handles them, are often difficult but yet an important concept for programmers to grasp. The manner in which Progress handles transactions is one of the unique and powerful features of the 4GL. It is also an area that we tend to struggle with usually because we imagine that the subject is more complex than it is in reality. This is an important subject, however, as with a little bad planning and careless programming it is possible to adversely and dangerous affect the behavior of your application from both a user interface point of view and a performance and "physical" database point of view. Transaction Scope Overview A transaction scope is logical grouping of changes being carried out to data that Progress guarantees will either be committed as a whole or UNDO ne as a whole. Reasons for undoing a transaction will range from a user deciding to abort the current set of changes (pressing F4 for example), to applications errors, to hardware failure.

Each completed transaction is guaranteed to have been written permanently to the database whilst any incomplete transactions will not be written to the database of they are interrupted. If you are unsure whether a transaction is currently active in your program use the TRANSACTION function which will return true if a transaction is currently active. Default Block Scop e Progress code is structured in blocks. These take the form of procedures, triggers, DO blocks (including IF / THEN DO ), FOR EACH and REPEAT . Of these the procedures, triggers, FOR EACH , DO ON ERROR and REPEAT will start a transation if there is a find with an EXCLUSIVE-LOCK in their block. This meanes that should a change be made to the data or a record found with an exclusive lock within these blocks, a transaction will be scoped to the bounds of those blocks. DO blocks have weak transaction scoping. If a change to data is made to a DO block then the transaction is scoped to the next outer transaction block. Ejemplo # 1 REPEAT: /* transaction starts here */ /* some code ....... * / FIND FIRST Order EXCLUSIVE-LOCK NO-WAIT NO-ERROR. /* Check locked status ....... * / UPDATE Order. /* some code ....... * / END. /*transaction ends here */ Example #2 REPEAT: /* transaction DOES NOT start here */ /* some code ....... * / REPEAT: /* transaction starts here */ FIND FIRST Order EXCLUSIVE-LOCK NO-WAIT NO-ERROR. /* Check locked status ....... * / UPDATE Order. END. /* transaction ends here */ /* some code ....... * / END. /* repeat */ Ejemplo # 3 REPEAT: /* transaction starts here */ /* some code */ DO WHILE TRUE:

FIND FIRST Order EXCLUSIVE-LOCK NO-WAIT NO-ERROR. /* Check locked status ....... * / UPDATE Order. END. /* DO WHILE */ /* some code ....... * / END. /*transaction ends here */ Example #4 /* start of a procedure transaction starts here */ FIND FIRST Customer EXCLUSIVE-LOCK NO-WAIT NO-ERROR. /* Check locked status ....... * / UPDATE Customer. /* Some code */ REPEAT: /* some code.... * / FIND NEXT Order OF Customer EXCLUSIVE-LOCK NO-WAIT NOERROR. /* Check locked status ....... * / UPDATE Order. /* some code.... * / END. /*end of the procedure transaction ends here */ Controlling Transactions It is possible to force any block to start a transaction by using the TRANSACTION keyword (note this differs from the TRANSACTION function mentioned above). This method can be used to both increase and decrease the size of a transaction. Take Example 4 from above: Example #4 /* start of a procedure transaction starts here */ DO TRANSACTION: /* Transaction starts here */ FIND FIRST Customer EXCLUSIVE-LOCK NO-WAIT NO-ERROR. /* Check locked status ....... * / UPDATE Customer. /* Some code */ END. /* Transaction ends here */ /* some code */ REPEAT: /* some code.... * / DO TRANSACTION: /* Another Transaction starts here */

FIND NEXT Order OF Customer EXCLUSIVE-LOCK NO-WAIT NOERROR. /* Check locked status ....... * / UPDATE Order. /* some code.... * / END. /* Second Transaction ends here */ END. /*end of the procedure */ The transactions in this example have now been scoped in a much more granular fashion. You may want to increase the scope of a transaction boundary: Example #5 DO TRANSACTION: /* Transaction starts here */ FOR EACH Order EXCLUSIVE-LOCK: DELETE Order. END. END. /* Transaction End */ If a system crash occurs here none of the Order records will be deleted. Of course this scenario also holds locks on all the records until the end of the transaction. Sub-transactions With Progress it is only possible to have one active transaction at a time. If a transaction block becomes part of an existing transaction it will form a sub-transaction. Sub-transactions can be used to UNDO parts of a transaction, however, the changes made in a sub-transaction do not get committed until the end of the main transaction. One of the most common ways of starting a sub-transaction is by calling another procedure whilst a transaction is active. Example #6 DO TRANSACTION ON ERROR UNDO, RETRY: /* transaction starts here */ IF RETRY THEN MESSAGE "You've undone your customer changes as well." IF NOT CAN-FIND Customer OF WHERE Customer-Name = "Test") THEN RUN newcust.p. FIND FIRST Order EXCLUSIVE-LOCK. UPDATE Order WITH 2 COLUMN. END.

/**** newcust.p ***** /* Program to add a new customer */ /* some code */ DO TRANSACTION ON-ERROR UNDO, LEAVE: /* start a sub transaction */ FIND FIRST Customer EXCLUSIVE-LOCK. UPDATE Customer WITH 2 COLUMNS. END. /* end a sub transaction */ The program newcust.p may not be expecting to be called within another transaction. Any update made in newcust.p can be rolled back in the calling routine if the user presses F4. Another side effect of this scenario is that a lock will be maintained on the Customer record until the end of the main transaction in the calling procedure. Record Locks and Scope Understanding Record Locking and Record Scope are essential in order to produce an effective program design. Record Locks Progress has row-level locking. This means it locks individual records at a time (as opposed to pages or tables). Two types of lock are supported, they are the SHARE-LOCK and the EXCLUSIVELOCK . In addition, Progress can read records with NO-LOCK . A SHARE-LOCK allows a record to be read by more than one user so long as that record is not being modified. A SHARE-LOCK gets upgraded to an EXCLUSIVE-LOCK if the modification on that record begins. An EXCLUSIVE-LOCK prevents any other user modifying or placing a SHARE-LOCK on a record. NO-LOCK allows the record to be read no matter what state another user has it in. It cannot however be modified. NO-LOCK allows dirty reads. In other words, the data that is being read may not have been committed to the database. The Progress default for a record is SHARE-LOCK as this provides the user with the most protection. However, this option is not recommended unless absolutely required. In general, the developer should know what is going to happen to the record and read it with a NO-LOCK or an EXCLUSIVE-LOCK .

Record Scope This subject relates to how long information in a Progress record buffer remains active and by association how long Progress keeps a lock on the record. Record locks are held for the longest of the transaction scope or record buffer scope. It is possible for a record buffer to have a wider scope that the transaction scope. Locks are held on a record not a buffer (remember it is possible to have multiple buffers pointing to one record). Example #7 FIND FIRST Customer. /* Some code */ DO TRANSACTION: /* transaction start */ UPDATE Customer WITH 2 COLUMNS. END. /* transaction end */ /* Some code */ PAUSE. The record buffer spans the whole of this procedure, including the PAUSE statement. The first FIND will instigate a SHARE-LOCK on the customer record. When the DO TRANSACTION is encountered the SHARE-LOCK gets upgraded to an EXCLUSIVE-LOCK . At the end of the transaction the changes to the record are committed and the lock on the record is down graded to a SHARED-LOCK . Example #8 FIND FIRST Customer NO-LOCK. /* Some code */ DO TRANSACTION: /* transaction starts */ FIND FIRST Customer EXCLUSIVE-LOCK. UPDATE Customer WITH 2 COLUMNS. END. /*SHARE-LOCK on Customer record is active */ Note that in the above example the lock status after the end of the transaction is still SHARE-LOCK . In other words, the record can only be read not modified by another user in this state. Note that finding another record in the same table will release the SHARE-LOCK . The RELEASE statement can also be used to clear out a record buffer and release the locks on that record at the end of the transaction.

Example #9 FIND FIRST Customer NO-LOCK. /* Some code */ DO TRANSACTION: /* transaction start */ FIND FIRST Customer EXCLUSIVE-LOCK. UPDATE Customer WITH 2 COLUMNS. RELEASE Customer. END. /* transaction end, No more locks held */ /* Some code */ PAUSE. In this example the lock is released at the end of the transaction but the Customer buffer is no longer available. RELEASE is a bit of a cop-out indicating a failure to properly control your record and transaction scopes. In addition it behaves differently if it is used in a sub-procedure that has been called within an existing record scope. In this case the lock is not released but downgraded to a SHARE-LOCK at the end of the procedure. Finally, it is possible to narrow (or increase) the scope of your record by using the DO FOR tablename construct. This strongly scopes the record to the block. No references to the buffer can be made outside the block without a subsequent FIND . Example #10 DO TRANSACTION: /* transaction start */ FIND FAST Customer EXCLUSIVE-LOCK. UPDATE Customer WITH 2 COLUMNS. RELEASE Customer. END. /* transaction end, No more locks held */ IF AVAILABLE Customer THEN MESSAGE "Customer record is available" The free reference to Customer outside the transaction boundary effectively increase the scope of that record (but not the transaction). The following example ensures that the record is not available outside the bounds of the transaction. In fact, it should not compile . Example #11 DO FOR Customer TRANSACTION: /* transaction start *? FIND FIRST Customer EXCLUSIVE-LOCK. UPDATE Customer WITH 2 COLUMNS.

RELEASE Customer. END. /* transaction end, No more locks held */ IF AVAILABLE Customer THEN MESSAGE "Customer record is available". Using XREF and Listings Using the Progress XREF and Listings compiler options can give invaluable insight into a program and are often useful in debugging. When a program has been completed, it should be compiled to produce two extra files. These are the LISTING file and the XREF (cross-reference) file. These files contain vital information, which will help ensure that your programs behave as expected. Use these files to help with unit testing and code reviews. Listados The listing file expands include files and numbers the program lines by block. At the end of the listing is a summary of each block within the procedure, the procedure itself being the main block. The record buffers and transaction that are scoped to the block are shown, as are the frame scopes. Use the COMPILE filename.p LISTING filename.lst option form the PROGRESS editor of the Compile option in the Application Compiler to produce the output file. Example Listing 1 showlist.p 2 3 {} Line Blk 4 -- ---- --5 1 1 DO FOR Account: 6 2 2 DO TRANSACTION: /* start of a transaction */ 7 3 2 FIND FIRST account EXCLUSIVE-LOCK 8 4 2 MESSAGE TRANSACTION. /* "yes" or "no" */ 9 5 2 PAUSE. 10 6 1 END. 11 7 1 12 8 2 REPEAT: /* start of a transaction */ 13 9 2 FIND FIRST policy_header EXCLUSIVE-LOCK. 14 10 2 LEAVE. 15 11 1 END. 16 12 1 17 13 1 /* shows the transaction is complete */ 18 14 1 MESSAGE TRANSACTION.

19 15 1 PAUSE 20 16 END. /* DO FOR Account */ 21 23 File Name Line Blk Type Tran Blk. Etiqueta 24 ---------- ---- ------------ ---- ------------------25 showlist.p 0 Procedure No 26 showlist.p 1 Do No 27 Buffers: policypl.Account 28 29 showlist.p 2 Do Yes 30 showlist.p 8 Repeat Yes 31 Buffers:policypl.Office_Header 32 Each block start has been highlighted along with the lines of interest at the bottom of the report. The above listing shows that the record buffer for Account is scoped to the outer DO FOR Account: block. That there is no transaction scoped to this block. The inner DO TRANSACTION block has a transaction scoped to it. The REPEAT block has both a record buffer (Office_Header) and a transaction scoped to it. XREF The cross reference compile option writes cross reference information between procedures and PROGRESS objects, including procedures, include files, tables, fields indices, variables frames and character strings. Developers must use this facility to check the efficiency of their queries. Whenever a query is used, a SEARCH entry will be made in the XREF file. This is followed by the table name and the name of the index used to resolve the query. If the query is unbracketed (ie there are no criteria given to narrow down the search) or PROGRESS is unable to use an index to resolve the query then the phrase WHOLE-INDEX appears after the index name. In the latter instance, the index name is the primary index, which only gives the order in which the records are returned. The rest of the query will be resolved by searching through the whole table. This scenario should be avoided. Example Xref Program FIND FIRST Account NO-LOCK. /* unbracketed search - no conditions */ /* this next one is bracketed by a non-indexed field */ FIND FIRST Office_Header. WHERE Office_Header.Effective_Date = TODAY NO-LOCK

/* this one is bracketed by a field indexed using a 2nd index */ FIND FIRST Office_Header. WHERE Office_Header.Account_No = Account.Account_No NOLOCK. This produces a number of lines, for index usage look for lines with SEARCH in them. As these XREF lines show: Example Xref Output Showref.p showxref.p 1 COMPILE showxref.p Showref.p showxref.p 1 SEARCH Account main_key WHOLE-INDEX Showref.p showxref.p 3 SEARCH Office_Header main_key WHOLEINDEX Showref.p showxref.p 6 SEARCH Office_Header account The second line relates to the unbracketed FIND statement, this is a valid scenario. The third line shows a bracketed search (using Effective_Date) that cannot be resolved using an index. The primary index name (main_key) indicates the order in which the records will be returned and the WHOLE-INDEX phrases indicates that the whole table will have to be searched to resolve this query. This should be considered a bug as it will cause severe performance problems. The final highlighted line shows a bracketed query that has been resolved using an index (account). This index was inspected and looks suitable as Account_no (the bracketing field) is also the first component in that index.