Record Maps are implemented by a set of two or more classes. The primary class (known as the RecordMap class) extends EnsLib.RecordMap.RecordMap and comprises an XData section and a couple of get and put methods. The second class (known as the Record class) is typically a generated one, and by default is named by appending a .Record suffix onto the name of the primary class. The record class is used to persist rows of record data.

For example:

• User.Customer extends EnsLib.RecordMap.RecordMap and its XData section contains /Record/@targetclassname="User.Customer.Record"
• User.Customer.Record extends %Persistent, Ens.Request, EnsLib.RecordMap.Base and is normally generated from the main class, User.Customer. It has a parameter RECORDMAPGENERATED whose value is 1 if this is the case.

Some record maps generate more than one class. The extra generated classes are typically serial classes used by the record class. For example, in the ENSDEMO namespace:

• Demo.RecordMap.Map.FixedWidth generates Demo.RecordMap.Map.FixedWidth.Record and Demo.RecordMap.Map.FixedWidth.Record.HomeAddress
• Demo.RecordMap.Map.Delimited generates Demo.RecordMap.Map.Delimited.Record, Demo.RecordMap.Map.Delimited.Record.HomeAddress and Demo.RecordMap.Map.Delimited.Record.WorkAddress

Some record maps are configured so that their records get assembled into batches. In this case its RecordMap class specifies a generated batch class which has a one-to-many relationship with the Record class. In ENSDEMO the Demo.RecordMap.Map.Delimited recordmap class specifies Demo.RecordMap.Map.Delimited.Batch as its batch class, and that class has a one-to-many relationship with the Demo.RecordMap.Map.Delimited.Record record class.

If it becomes necessary to make manual modifications to a generated class, the programmer should set RECORDMAPGENERATED=0 to stop Portal's Generate button overwriting the manual changes.