Document Overview *

This Manual is intended to *

This Manual is not intended to *

Database Design Considerations *

Definition *

Tables (or Files) *

Fields (or Columns) *

Indexes *

Referential Integrity *

Naming Conventions *

General Naming Conventions *

Procedures *

Variables *

Widgets *

Frames *

Buffers *

Streams *

Blocks *

Workfiles and Temp Tables *

External References *

Procedure Structure *

General Outline *

Program Header *

Variables *

Other Defines *

Forms *

Startup Routines *

Procedure Style *

Indentation *

Statements Per Line *

Capitalization *

Block Labels *

Punctuation *

Comments *

Dictionary Formats and Labels *

Include Files *

If / Then / Else *

Case Statement *

Program Exits *

Listing Field Names *

Listing Format Phrase Options *

Listing Frame Phrase Options *

Keywords to Not Use *

Keywords to Avoid *

Abbreviations *

Miscellaneous *

Frames *

Transactions *

Error Handling *

Record Reading *

Record Locking *

Portability *

Terminals *

Names *

Workfiles *

Operating Systems *

Color *

Operating System Specific *

Performance *

Coding Techniques *

Multi-Database *

Using Multiple Databases *

Understanding Transactions *

Transaction Scope Overview *

Default Block Scope *

Controlling Transactions *

Sub-transactions *

Record Locks and Scope *

Record Locks *

Record Scope *

Using XREF and Listings *

Listings *

XREF *

• Set design and programming standards for Progress programmers
• Provide guidelines for team and project leaders during code reviews

• Teach anyone how to program in Progress.

• Foreign key fields have the same field name as they do in their original table.
• Duplicate field names should not be used except where a foreign key is being defined.
• With field and table names, underscores ("_") not hyphens ("-") should be used to avoid potential problems with third party SQL implementations.
• Field level help should be entered.
• Table and field descriptions should be entered.
• Default field formats are entered.
• There should always be one unique primary index per table.
• The field that repeats the most should be the first component followed by the next most repeating field. This makes searching much more efficient and helps with index compression (note: the most repeating field is the one whose value changes the least over multiple records!).
• Do not add or delete fields / tables / indices without carrying out impact analysis to anticipate all the effects of the change.

• If DOS compatibility is desired, file names should be limited to 8 characters even though Progress allows 32. This restriction is lifted in Progress Version 6 with the addition of an 8 character "dump" name to the dictionary.
• Another reason to keep file names short is that Progress stores these names literally in the compiled R-code. Therefore, long names have a direct impact on R-code size. This also applies to field, variable, and workfile names.
• Use include files for the dictionary deletion validation. This allows the deletion criteria to be changed even if a database may be in use by other users. Simply edit the include file and recompile the affected procedures.

• It is recommended that field names be limited to 12 characters, even though Progress allows 32.
• Be aware of the limitations of using the RECID datatype. During a data dump using EXPORT, Progress converts the RECID to the unknown value (?) . Using stored RECIDs normally requires the developer to write custom dump and load procedures.
• For DECIMAL fields, the number of decimals stored should match, or exceed the number of decimals displayed in the format.
• The use of SIDE-LABELS will cause DECIMAL fields using the formatting ">" character to lose decimal alignment depending upon the size of the number displayed (even if the format is the same size). Therefore, the use of the "z" formatting character is recommended.
• The formats for logical data types should always have the positive format on the left and the negative on the right. A format of "No/Yes" could cause severe logic problems.
• For character field formats, avoid using the "!" and "9" formatting characters unless a character MUST be entered because Progress does not allow a blank or non-alphabetic character when using this format.
• The length of a label should be limited to 14 so that the label will not be truncated when displaying WITH 1 COLUMN or WITH 2 COLUMNS. If 3 or 4 COLUMNS are used frequently, the label should not exceed 12 characters.
• Column-Labels should be the same width or less than the format of the field to act as a "short label" for tight reports and screens. If screen space is limited don't stack column labels more than 2 levels deep.

• The initial value for a logical field should always be yes or no. Consider the following:

• Mandatory should generally be set to YES for fields where the unknown value might cause a problem. This is to prevent the logical data corruption described in the previous example.
• Progress does not check the syntax of a validation expression until a procedure is compiled that utilizes that expression. Whenever a valexp is entered or modified, upon exiting the dictionary test the validation by using:

• The primary index should be the index that is used most often for traversing a file with a FOR EACH, not the index mainly used for random access. This will cause the data to be dumped in that order. When the data is subsequently reloaded into a new database, the RECIDs are assigned sequentially to the records during the load. When the primary index is built, it will be build with references to these sequential recids. All other indexes for that will be built with the recids in non-sequential order.
• Character index components should be defined as Abbreviate set to 'yes' (unless the component is not the last component of the index). This will allow the use of a PROMPT-FOR / FIND USING combination without using the BEGINS function.
• Do not create indexes that share the same components.

• It is recommended that index names be limited to 12 characters.

• a value is input to a foreign key field during user interaction
• an entry is written to the database
• an entry is being deleted

Referential integrity can carried out in three places, the data dictionary, database triggers (CREATE, FIND, ASSIGN, WRITE and DELETE) and the application code itself.

Use the DELETE trigger to enforce deletion integrity and audit and the WRITE trigger for audit.

• All PROGRESS reserved words must be entirely in upper case. Other programming entities, such as variable names, will use either lower case or a mixture of upper and lower case, as described below for various specific instances. For those instances not discussed below, all lower case is the preferred option.

• If compatibility with Progress conventions is desired, the following file name extensions should be used:

• To distinguish variables from database fields, it is recommended that a prefix or suffix be used to set the actual name off. This makes it much easier for the maintenance programmer to track variables through a chain of procedures. If the variable is defined LIKE a field, the field name should be contained in the variable name.

• Because Version 6 allows the construct db.file.field, it is recommended that database names and file/buffers names be distinct to prevent confusion over database.file and file.field.

• A number of other widgets are available in V7&V8. The naming conventions for these should be the same as for field and file names but with a prefix indicating what type of object is being referred to. These are as follows:

• As with variables, frame names should also have a prefix or suffix to set them off. In addition the frame should be identified by type (local or shared). In multi-screen conversations, the frame may also need to be numbered.

• Buffers should also have a suffix/prefix and be identified as shared or local. The database file name that the buffer represents should be contained in the name.

• Streams should have a suffix or prefix.

• Block labels are to be on a separate line above the block statement.

• Block labels should have a suffix or prefix and give some indication as to the nesting level of the block being labeled.

• Labeled blocks should have the block label as a comment next to the END statement for the block, include the colon in the block label for quick/easy access to the beginning and ending of the block.

• Progress allows duplicate block labels in the same procedure, however, this practice is discouraged because of the potential for confusion.

• To distinguish workfiles from database fields, a prefix should be used. If the workfile represents a dictionary file, the workfile name should contain the dictionary file name. This will make it easier to locate when doing text searches.

• When an index consists of only one field, the name of the index should be the same as the field.
• When an index has more than one component, the index should attempt to paraphrase the fields used in the index.

• When Progress output is directed to an ASCII file, the following naming conventions should apply.
• For portability, the file name should not exceed 8 characters with a 3 character suffix.
• To prevent collisions with other users who may also be writing ASCII files to disk, one of the following conventions can be used:
• Write to the user's home directory or specially designated temporary directory.
• Make the name of the file unique. Usually the ETIME function with a tie breaker such as USERID is sufficient to prevent name conflicts.
• Use a .d suffix for files that contain EXPORTed data.

1. Header
2. Variables
3. Other Definitions
4. Forms
5. Procedure Body
6. Exit Point

1. Program Name
2. Application Name / Module
3. Program Location / Directory
4. Copyright notice
5. Modification History / Revisions / Initials / Date
6. Reasons for each change
7. Include file list
8. Files read (Input)
9. Files written (Output)
10. Purpose and general description of program

• All variables, workfiles, and define parameters should be defined as no-undo. All exceptions must be commented to avoid future changes that will cause problems.

• Variables should always be defined LIKE file.field-name whenever appropriate for self-documentation and ease of maintenance. One possible disadvantage is that LIKE requires that a session be connected to the appropriate database.
• Variables should not have the same name as a database field or a database (Version 6) for clarity.
• All NEW SHARED/SHARED variables should be stored in include files passing NEW as a parameter in the procedure where initially defined. This will make maintenance easier and also prevent problems with conflicts in DATATYPE, NO-UNDO, EXTENT, etc.
• When defining variables, all definition options should be aligned for readability.

• No variables should be defined in a statement other than a DEFINE statement. Progress allows variable definitions in DISPLAY, UPDATE, FORM and other data handling statements, but they are difficult to locate and maintain when DEFINEd in this way.

1. new global shared stream
2. new shared stream
3. shared stream
4. stream
5. new shared buffer
6. shared buffer
7. buffer
8. new shared workfile
9. shared workfile
10. workfile
11. new shared frame
12. shared frame
13. input parameter
14. output parameter
15. input-output parameter

1. New shared frame include file forms
2. Shared frame include file forms
3. Include file forms
4. Local forms

• All FRAME Phrase options associated with a frame should be listed only on the FORM statement for ease of maintenance.
• All forms described in a program should be given explicit frame names. This is particularly important when FORMs are placed at the beginning of a procedure, scoping them to the procedure block.

• Any include file startup routines such as screen headings and security checks should be listed together.
• Variable initialization should also done in this section. Exit Point:
• All procedures should have a common exit point. This is usually a RETURN statement on the last line of the procedure. A RETURN anywhere else in the procedure is similar to a GOTO statement in another language. The only difference is that RETURN can only go back to the calling procedure.
• This exit point should also be used to HIDE any frames that do not need to be visible when returning to the calling procedure and initialize any shared variables that need to be.

• Recommended indentation is 3 spaces.
• When the level of block nesting gets to the point where lines are being "broken" prematurely, 2 space indentation is allowed, although this can be a symptom of poor program design.
• All statements contained within a block must be indented:

• END statements will always line up with the block statement they are ending.

• Only one statement per line is allowed for readability.
• A statement may not be extended by use of the tilde (~).

• All code will be in lower case with the exception of the block labels and text inside a comment.

• Major REPEAT and FOR EACH blocks should be preceded with a block label that describes the function of the block.
• The label should be on a line by itself above the block header (see preceding example).
• DO blocks only require labels when they are used for some purpose other than grouping statements together such as defining a new frame or changing transaction scope; or when they are more than 10-12 lines long.
• Any block that is subject to a NEXT, LEAVE, or UNDO statement must have a block label. The NEXT, LEAVE, or UNDO statement should explicitly reference that label.

• All Progress statements are terminated with periods except block labels and block headers (REPEAT/FOR/DO) which are terminated with a colon.

• All block headers (FOR EACH/REPEAT) should be preceded with a comment describing the purpose of the block, especially if that block is a transaction block.
• All END statements for blocks should be followed with a comment that "matches" the END to the block header statement. The only exceptions would be blocks that contain very few statements

• Multi-line comments should be in the form:

• Single-line comments should be in the form:

• No need to comment the END statement:

• Labels, formats, validation and help from the dictionary should be used rather than overriding in the procedure.
• When overriding dictionary labels, do so on the FORM or DEFINE FRAME statement if one is being used to define the frame.
• For variables specify LABEL and FORMAT in the DEFINE or FORM statement rather than on data handling statements such as DISPLAY and UPDATE.
• 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.

• 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 (e.g. 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:

• Include file coding style, simple parameters:

• Include file coding style, multiple parameters:

• Include files should not terminate a block started outside of the include file. Conversely, an include file should not start a block that ends outside of the include file.
• Do not hardcode a path name into the include file reference. PROPATH can be used (and dynamically adjusted as necessary) to change the directories at compile time.
• Do not put comments within curly brackets of an include file call, as the compiler tends to get confused.

• The use of NOT should be avoided. Good style dictates testing a positive condition whenever possible. Okay to use when testing logical functions and variables.
• Mixed AND and OR conditions should be avoided, but if used the order of evaluation should be explicitly noted through the use of parentheses. Put each condition on a separate line aligning the AND/ORs vertically.

• For a group of conditions connected by AND, the most unlikely condition(s) should be tested first.
• For a group of conditions connected by OR, the most likely condition(s) should be tested first.
• 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.

• The only exception would be a nested IF/THEN/ELSE when there was only one possible statement.

• ELSE statements should appear on separate lines, aligned with the IF statements to which they apply.
• For compound tests, align the ORs and ANDs.

• When testing logical fields or variables, do not use TRUE, FALSE, YES, and NO for comparisons because of reduced performance and larger R-code.
• Use the Progress CASE statement (V7) when ever possible. If it is necessary to use nested IF statements, use the following constructs:

• The use of "null" THENs and ELSEs is not allowed.

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

• 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.

• 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:

• 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.

• When displaying a subset of an array, use the following notation:

• When FORMAT Phrase options are used, they should be aligned vertically or horizontally.

• Arrange frame phrase options in a manner that avoids placement of two integers together for different options.

• STOP statement: Useful for testing only.
• 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.

• 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.

• 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:

• The following keywords may be abbreviated, but not as much as Progress allows:

• All other Progress supported abbreviations are allowed.

• Hard coding of values into any program is discouraged with the following exceptions: Parameters passed to an include file and unchanging constants (e.g. 12 months in a year).
• Do not hardcode keylabels into a procedure.

• Long MESSAGEs that will not fit on one line should be coded:

• Note in the preceding example that the message string is delimited with a blank on each end. This suggestion also pertains to TITLEs.

• Algebraic style logical operators are preferred over the FORTRAN style. Either style is acceptable.

• When using DO WHILE/REPEAT WHILE loops, always test for a "less than" or "greater than" condition rather than "equal to". This prevents infinite looping if the "equal to" condition is never met.

• TRIM character field sensitive to leading blanks (i.e. sort fields).
• The fields in a FORM statement should be listed vertically one per line for ease of maintenance.

• Frames should be standardized using the default box or NO-BOX. Frames used for printed output should use NO-BOX to recover the blank line (and columns) that Progress allocates for the "invisible" graphics box at the top of the frame.
• For standardized frame widths on reports, use standard WIDTHs that match the characters per inch normally used on the printer:

• Avoid widths that exceed 132 columns particularly because this compromises the ability for a user to send a wide report to their terminal (using the TERMINAL statement) without wrapping. In addition, it means that there is not need to support condensed/compressed print for a potentially variety of printers.
• To make maximum use of paper, but still leave an adequate margin, use PAGE-SIZE 60.

• Block headers that define a transaction should explicitly use the TRANSACTION keyword for self-documentation. This will allow the compiler to catch possible transaction errors.

• A Progress error (e.g. 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.

• 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.

• USING may be used instead of WHERE because USING specifies the key being used.
• For good style the left side of the comparison in a WHERE clause will always be the field used to retrieve the record.

• If the transaction level and framing support it, all related records should be found in a single FOR EACH statement.

• When there are multiple conditions in the WHERE clause, use the following form (note the indentation):

• When retrieving one-to-one relationship records in a FOR statement, the EACH should be used in case the record is missing. If there is a possibility that a record could be missing, it should be trapped using FIND/NO-ERROR and the AVAILABLE function.
• When a PROMPT-FOR is followed by a FIND, use NO-ERROR on the FIND statement unless you wish to use the Progress default error handling (an error message followed by UNDO, RETRY of the closest UNDO block). FIND/NO-ERROR will always be followed by a test with the AVAILABLE function.
• FIND/NO-WAIT will always be followed by a test with the LOCKED function.
• The order of comparisons in a WHERE clause should follow this hierarchy:

1. Fields of the index being used by the FIND/FOR EACH statement. The comparisons should be in the same order as the fields occur in the index.
2. Fields from indexes not being used by the FIND/FOR EACH.
3. Non-indexed fields.
4. Variables.
5. Expressions.

• 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.

• 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.

• Use NO-LOCK whenever the state of the information is not important (e.g. most inquiries and reports) to reduce contention and improve performance.
• When it is reasonably certain that a user will be updating an existing record and that record will not cause locking contention, read the record EXCLUSIVE-LOCK. This will reduce the potential for deadly embrace as well as offer a small performance gain.
• SHARE-LOCK should never be used. With SHARE-LOCK the possibility always exists that deadly embraces, or deadlock, might occur.
• Always explicitly state the lock status. The use of the -NL startup option is forbidden.

• Because the possibility exists that Progress may be run using terminals with a varying number of available lines (25 for DOS, 24 for most ASCII terminals), use the following functions to calculate the available lines and make maximum use of the available screen space.

• The same situation exists with space taking and non-space taking terminals. To take maximum advantage of available screen space and still maintain portability, the following is recommended:
• All frames with data entry or using color attributes will be use ATTR-SPACE in the Frame Phrase for that frame.
• All procedures will be compiled with the NO-ATTR-SPACE option.

• If DOS compatibility is needed, the following items will be limited to 8 characters in length.

• 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.

• 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.

• Use the OPSYS function to shield operating system calls.

• Use the COLOR VALUE (color-variable) in all frame phrases. 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.

• 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.

• 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:

• When there are more than 1 assignments next to each other, use the ASSIGN statement.

• 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 BUFFERs 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 sub-procedure.

• 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:

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 ORed together.

• Reduce start/stop of transactions in a tight loop (e.g. batch creation of a large number of records).

• 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 WORKFILEs 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.

• 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.

A transaction scope is logical grouping of changes being carried out to data that Progress guarantees will either be committed as a whole or UNDOne 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.

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.

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.

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.

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).

Two types of lock are supported, they are the SHARE-LOCK and the EXCLUSIVE-LOCK. 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.

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.

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.

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.

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.

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.

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.

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 (i.e. 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.

This produces a number of lines, for index usage look for lines with SEARCH in them. As these XREF lines show:

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.