2 1 Field Naming Conventions

LANSA Application Design

2.1 Field Naming Conventions

A suggested naming standard for fields in the data dictionary is:

For In-House Development

For Package Development

XXXXXXiii

PPXXXXiii

 

Where the following points apply:

  • No field name should be longer than 9 characters.
  • No field name should contain a "#" (hash/number) symbol or an "@" (at) symbol.

    The XXXXXX / PPXXXX part of the name should be from 1 to 6 characters in length and as meaningful as possible given the size limitations. For example:

 

In-House Development

PARTNO

Part number

CUSTNO

Customer number

ITEMNO

Item number

SALQTY

Sales quantity

SALAMT

Sales amount

SALAVG

Sales average

 

 

Package Development

OEPTNO

Part number

OECUST

Customer number

OEITEM

Item number

MKSAQT

Sales quantity

MKSAAM

Sales amount

MKSAVG

Sales average

 

 

   OEPTNO, OECUST, and OEITEM are order entry packages, and MKSAQT, MKSAAM, and MKSAVG are marketing packages.

  • "iii" is optional and should only be used for "working" or "temporary" versions of the original XXXXXX / PPXXXX field in RDML programs. The iii suffix should be standardized and only a finite number of variations allowed. For example:

NXT

Next value of the field

PRV

Previous value of the field

WRK

Working value of the field

USE

Exchanged/using value of the field

RN1

First rename of the field

RQS

Requested value of the field

VIR

Virtual field definition

TOT

Totaled value of field                

 

 

  • File definitions should only ever use the XXXXXX or PPXXXXversion of the field name (with the possible exception of virtual fields). The versions with the iii suffix should be restricted for use as "working" fields within RDML programs.
  • All "iii" suffix versions of the field should be defined in the dictionary. No RDML program should specifically define such fields, even when the correct REFFLD (refer field) option is used. This greatly increases the cross-referencing power of LANSA and standardizes program work variable naming conventions.
  • In a "package" environment the PP component of the name should be standardized. For example:

GL

General ledger

AR

Accounts receivable

OE

Order entry

 

 

One advantage of this type of naming standard is that when an attempt is made to change the dictionary and field name XXXXXX or PPXXXX is specified, all the iii variations will also appear due to LANSA's generic search and display facility. This serves as a continual prompt to remember to change/check all the versions of the same field.

The LANSA Product Support Department in Australia maintains a register of all known PP prefixes. If you are assigning a PP prefix it may be advisable to contact your product vendor to check that the prefix has not already been used, and to have your prefix added to the register to prevent others from using it.