Record Class Methods

In this section, we discuss each Record class method. The methods are discussed in alphabetical order.

Syntax

CompareFields(recordobject)

Description

The CompareFields method compares all like-named fields of the record object executing the method with the specified record object recordobject.

Parameters

Field or Control	Definition
`recordobject`	Specify a record object for use in the comparison. The specified record object does not have to refer to the same record as the record object executing the method.

Returns

A Boolean value; True if all like-named fields have the same value.

Example

&REC = GetRecord(RECORD.OP_METH_VW);
&REC2 = GetRecord(RECORD.OPC_METH);
If &REC2.CompareFields(&REC) Then
    WinMessage("All liked named fields have the same value");
End-If;

Syntax

CopyChangedFieldsTo(recordobject)

Description

The CopyChangedFieldsTo method copies all like-named field values that have changed from the record object executing the method to the specified record object recordobject. This copies only changed field values. To copy all field values, use the CopyFieldsTo method.

Note: This method works only with database records. The Component Processor doesn't track the contents of work records, so there is no changed value to use for copying changed fields.

Parameters

Field or Control	Definition
`recordobject`	Specify a record object to be copied to. The specified record object does not have to refer to the same record as the record object executing the method.

Returns

None.

Example

Local Record &REC, &REC2;

&REC = GetRecord(RECORD.OPC_METH);

/* make changes to the values of fields in the record */

&REC2 = CreateRecord(RECORD.OPC_METH_WORK);

&REC.CopyChangedFieldsTo(&REC2);

Syntax

CopyFieldsTo(recordobject[, DontCopyUnusedInSource [, DontCopyUnusedInDestination]] [,IsBatch])

Description

The CopyFieldsTo method copies all like-named field values from the record object executing the method to the specified record object recordobject. This copies all field values.

To copy only changed field values, use the CopyChangedFieldsTo method.

To restrict the copy to fields that have been marked as unused (set using the SetDBFieldNotUsed function) you can specify either DontCopyUnusedInSource or DontCopyUnusedInDestination.

Note: If you are copying to a derived work record, the IsChanged flag for the record is not set. Copying fields to a database record does set the IsChanged flag to True.

Parameters

Field or Control	Definition
`recordobject`	Specify a record object to be copied to. The specified record object does not have to refer to the same record as the record object executing the method.
`DontCopyUnusedInSource`	Specify this parameter to be True if you want to restrict the copy of fields to not include fields marked as unused in the record of the object performing the CopyFieldsTo method. This is the source record. The default value for this parameter is False, which means that there are no restrictions on the copy of unused fields as defined in the source record.
`DontCopyUnusedInDestination`	Specify this parameter to be True if you want to restrict the copy of fields to not include fields marked as unused in the recordobject record which is the destination record. Note: To specify this record to be true you must specify a value for `DontCopyUnusedInSource`. The default value for this parameter is False meaning that there are no restrictions on the copy of unused fields as defined in the destination record.
`IsBatch`	Specify whether this method is being called from an online program or from a batch program (such as an Application Engine program.) The default is false. Using this method may improve batch performance. When set to true, the system uses the FieldNotUsed information directly from the field properties already in the memory

Returns

None.

Example

Local Record &REC, &REC2;

&REC = GetRecord(RECORD.OPC_METH);
&REC2 = CreateRecord(RECORD.OPC_METH_WORK);
&REC.CopyFieldsTo(&REC2);

In the following example, records are copied into a record after being fetched.

Component number &displayNum;
Local SQL &sql;
Local Rowset &rs, &rs2;

&level0 = GetLevel0();
&displayNum = WS_NUM_ORDERS;

&rs = GetRowset(Record.WS_ORD_HDR_VW);
&rs.Flush();
WinMessage("1");
&sql = CreateSQL("%selectall(:1) where BUSINESS_UNIT=:2", Record.WS_ORD_HDR_VW, "M04");
WinMessage("2");
&rec = CreateRecord(Record.WS_ORD_HDR_VW);

For &i = 1 To &displayNum
   
   If &sql.Fetch(&rec) Then
      
      &rs.InsertRow(&i);
      
      &rec.copyfieldsto(&rs.GetRow(&i).WS_ORD_HDR_VW);
      
      &rs2 = &rs.GetRow(&i).GetRowset(1);
      &rs2.Select(Record.WS_ORD_LINE_VW, "where BUSINESS_UNIT=:1 and ORDER_NO=:2", &rec.BUSINESS_UNIT.value, &rec.ORDER_NO.value);
      
      /* Hide rows that do not contain Products */
      If &rs2 = Null Or None(&rs2.GetRow(1).WS_ORD_LINE_VW.ORDER_INT_LINE_NO.Value) Then
         For &j = 1 To &rs2.ActiveRowCount
            &rs2.GetRow(&j).Visible = False;
         End-For;
      End-If;
   End-If;
End-For;

&rs.GetRow(&i).Visible = False;

The following example is for unused record fields:

Local Record &From = CreateRecord(Record.QE_UPS_TIME);

/* setup the initial values */

&From.QE_FROM_ZIP.Value = "12345";
&From.QE_TO_ZIP.Value = "67890";
&From.QE_UPS_TIME_BUTTON.Value = "A";
&From.DESCRLONG.Value = "This is the from record.";

/* Now make one of the fields unused */
Local string &ToZip_Value = "77777";

/* start out clean with &To */
Local Record &To = CreateRecord(Record.QE_UPS_TIME);
&To.QE_TO_ZIP.Value = &ToZip_Value;
If SetDBFieldNotUsed(Field.QE_TO_ZIP, True) <> %MetaDataChange_Success Then
   MessageBox(0, "", 0, 0, "SSetDBFieldNotUsed(Field.QE_TO_ZIP, TRUE) fails??");
End-If;
/* Copy no unused fields from the source record */
&From.CopyFieldsTo(&To, True /* no unused fields from source */);

/* Copy to no unused fields in the destination */
&From.CopyFieldsTo(&To, False /* all fields from source */, True /* no unused fields in dest */);

/* Copy no unused fields either in source or destination */

&From.CopyFieldsTo(&To, True /* no unused fields from source */, True /* no unused fields in dest */);

/* Now finally make that field good again */

If SetDBFieldNotUsed(Field.QE_TO_ZIP, False) <> %MetaDataChange_Success Then
   MessageBox(0, "", 0, 0, "SSetDBFieldNotUsed(Field.QE_TO_ZIP, False) fails??");
End-If;

Syntax

Delete()

Description

The Delete method uses the key fields of the record and their values to build and execute a DELETE SQL statement which deletes the record (row of data) from the SQL data table.

This method, like the DeleteRow Rowset class method, initially marks the record or row as needing to be deleted. At save time the row is actually deleted from the database and cleared from the buffer.

Because this method results in a database change, it can be issued only in the following events:

SavePreChange
WorkFlow
SavePostChange

If your application is repeating the same instruction multiple times, such as doing a million DELETEs, use the SQL object with the BulkMode property set to True, rather than the record SQL methods.

For every record deleted by the Delete method, if the set language is not the base language and the record has related language records, the Delete method tries to do related language processing.

Parameters

None.

Returns

The result is True on successful completion, False if the record was not found. Any other conditions cause termination.

Example

Suppose that KEYF1 and KEYF2 are the two key fields of record definition MYRECORD. The following code deletes the database record that has KEYF1 equal to "A" and KEYF2 equal to "X":

Local record &REC;
&REC = CreateRecord(RECORD.MYRECORD);
&REC.KEYF1.Value = "A";
&REC.KEYF2.Value = "B";
&REC.MYRF3.Value = "X";
&REC.MYRF4.Value = "Y";
&REC.Insert();

Syntax

ExecuteEdits([editlevel]);

where editlevels is a list of values in the form:

editlevel1 [+ editlevel2] .  .  .]);

and where editleveln is one of the following constants:

%Edit_DateRange

%Edit_OneZero

%Edit_PromptTable

%Edit_Required

%Edit_TranslateTable

%Edit_YesNo

Description

The ExecuteEdits method executes the standard system edits on every field in the record. The types of edits performed depends on the editlevel. If no editlevel is specified, all system edits are executed. All editlevels are already defined for the record definition or for the field definition, that is:

Reasonable Date Range (Is the date contained within the specified reasonable date range?)
1/0 (Do all 1/0 fields contain only a 1 or 0?)
Prompt Table (Is field data contained in the specified prompt table?)
Required Field (Do all required fields contain data? For numeric or signed fields, it checks that they do not contain NULL or 0 values.)
Translate Table (Is field data contained in the specified translate table?)
Yes/No (Do all yes/no fields only contain only yes or no data?)

Note: ExecuteEdits does not perform any validation on DateTime fields.

If any of the edits fail, the status of the property IsEditError is set to False for the record. The field property EditError is set to True for any fields that are in error. In addition, the Field class properties MessageNumber and MessageSetNumber are set to the number of the returned message and message set number of the returned message, for each field in error.

You must use the SetEditTable method to set the prompt tables for fields that are defined with %EditTable in the record definition.

If you’re running an Application Engine program, and you want to do set based ExecuteEdits (as opposed to row-by-row) consider using the meta-SQL construct %ExecuteEdits.

See SetEditTable, EditError, MessageNumber, MessageSetNumber, Using Application Engine Meta-SQL.

Considerations for ExecuteEdits and SetEditTable

If an effective date is a key on the prompt table, and the record being edited doesn’t contain an EFFDT field, the current date and time is used as the key value.

If a SETID is a key on the prompt table, and the record being edited doesn’t contain a SETID field, the system looks for SETID on the other records in the current row first, then searches parent rows.

For all other keys, the value used to "select" the correct row in the prompt table record comes only from the record executing the method. No other records (or key field values) are used. You may get unexpected results if not all the keys for the prompt table are filled in (or filled in correctly.)

Considerations for ExecuteEdits and Numeric Fields

A zero (0) might or might not be a valid value for a numeric field. ExecuteEdits processes numeric fields in different ways, depending on whether the field is required:

If the numeric field is required: 0 is considered invalid.
If the numeric field is not required: 0 is considered valid.

Parameters

Field or Control	Definition
`editlevel`	Specifies the standard system edits to be performed against every field on every record. If `editlevel` isn’t specified, all system edits are performed. `editlevel` can be any of the following system variables. %Edit_DateRange %Edit_OneZero %Edit_PromptTable %Edit_Required %Edit_TranslateTable %Edit_YesNo

Field or Control

Definition

editlevel

Specifies the standard system edits to be performed against every field on every record. If editlevel isn’t specified, all system edits are performed. editlevel can be any of the following system variables.

%Edit_DateRange
%Edit_OneZero
%Edit_PromptTable
%Edit_Required
%Edit_TranslateTable
%Edit_YesNo

Returns

None.

Example

The following is an example of a call to execute Required Field and Prompt Table edits:

&REC.ExecuteEdits(%Edit_Required + %Edit_PromptTable);

The following is an example showing how ExecuteEdits() could be used:

&REC.ExecuteEdits();
If &REC.IsEditError Then
   LogError();  /*application specific call */
End-If;

Syntax

GetField({n | FIELD.fieldname})

Description

The GetField method instantiates a field object for the specified field associated with the record. This is the default method for the record object. This means that any record object, followed by a parameter list, acts as if GetField is specified.

Note: If the field you’re accessing has the same name as a record property (that is, Name or FieldCount) you can’t use the default method for accessing the field. You must specify GetField.

For example, the following is invalid for accessing the value of a field called NAME:

&NUMBER = &REC.NAME.Value;

You must use the following code to get the value of a field called NAME:

&NUMBER= &REC.GetField(FIELD.NAME).Value;

Parameters

Field or Control	Definition
`n` \| FIELD.`fieldname`	Specify a field to be used for instantiating the field object. You can specify either `n` or FIELD. `fieldname`. Specifying `n` creates a field object for the `nth` field in the record. This might be used if writing code that needs to examine all fields in a record without being aware of the name. Specifying FIELD. `fieldname` creates a field object for the field `fieldname`.

Note: There is no way to predict the order the fields will be accessed. Use the n option only if the order in which the fields are processed doesn’t matter.

Returns

A field object.

Example

&REC.GetField(FIELD.CHARACTER).Value = "Hello";

As GetField is the default method for a record object, the following code is identical to the previous code:

&REC.CHARACTER.VALUE = "Hello";

The following code creates an array containing all the names of all the fields in a related language record.

Local array of string &FIELD_LIST_ARRAY;
&FIELD_LIST_ARRAY = CreateArray();
For &I = 1 to &REC_RELATED_LANG.FieldCount
   &FIELD_LIST_ARRAY.Push(&REC_RELATED_LANG.GetField(&I).Name);
End-For;

The GetField method requires either FIELD.fieldname or a number. It won’t take a string field name. However, you can use the @ operator to convert the string field name into a FIELD.fieldname reference, as follows:

&REC = GetRecord();
&REC2 = GetLevel0(1).EMPL_CHECKLIST;
&FIELD2 = &REC.GetField(@ "FIELD." | &REC2.getfield(&I).Name);

The following code converts field name strings (using the @ symbol) to component names to get the value of all the fields in a subrecord. Note the code in Keyword style.

Function get_draft_dst_codes
   /* Load dst id codes into record structures */
   &DSTCODES = CreateRecord(RECORD.DR_DST_CODE_SBR);
   &DRAFTITEM = GetRecord(RECORD.DRAFT_ITEM);
   &DRAFTITEM.CopyFieldsTo(&DSTCODES);
   /* If any missing get from AR dist code, then Draft Type-BU, then BU */
   For &I = 1 To &DSTCODES.FieldCount
      If None(&DSTCODES.GetField(&I).Value) Then
         get_ar_dst_code();
         &NAME = &DSTCODES.GetField(&I).Name;
         If All(&DST.GetField(@ ("FIELD." | &NAME)).Value) Then
            &DSTCODES.GetField(&I).Value = &DST.GetField(@("FIELD." | &NAME)).Value;
         Else
            If All(&R_DRAFTBU.GetField(@("FIELD." | &NAME)).Value) Then
               &DSTCODES.GetField(&I).Value = &R_DRAFTBU.GetField(@("FIELD." | &NAME)).Value;
            Else
               &DSTCODES.GetField(&I).Value = &R_ARBU.GetField(@("FIELD." | &NAME)).Value;

            End-If;
         End-If;
      End-If;
   End-For;
   /* Copy the defaulted values back to draft item */
   &DSTCODES.CopyFieldsTo(&DRAFTITEM);   
End-Function;

Syntax

Insert()

Description

The Insert method uses the field names of the record and their values to build and execute an Insert SQL statement which adds the given record (row of data) to the SQL table.

Because this method results in a database change, it can only be issued in the following events:

SavePreChange
WorkFlow
SavePostChange

If your application is repeating the same instruction many times, such as doing a million INSERTs, use the SQL object with the BulkMode property set to True, rather than the record SQL methods.

If you're using a record created using CreateRecord, all fields are initially set to "", 0, or NULL, depending on the type of field. If you don't specify values for these fields, these initial values are written to the database when the insert is executed. If you want the default values for the fields inserted instead, use the SetDefault method prior to using the Insert method.

For every record inserted with the Insert method, if the set language is not the base language and the record has related language records, the Insert method tries to do related language processing.

Parameters

None.

Returns

The result is True on successful completion, False if there was a record with those keys already in the database, that is, if a duplicate record was found. Any other conditions cause termination.

Example

Suppose that KEYF1 and KEYF2 are the key fields of record definition MYRECORD, and that this record definition also contains the field definitions MYRF3, MYRF4. The following code adds a MYRECORD record (row of data) to the database, with KEYF1 set to "A", KEYF2 set to "B", MYRF3 set to "X", and MYRF4 set to "Y":

Local record &REC;
&REC = CreateRecord(RECORD.MYRECORD);
&REC.KEYF1.Value = "A";
&REC.KEYF2.Value = "B";
&REC.MYRF3.Value = "X";
&REC.MYRF4.Value = "Y";
&REC.Insert();

Syntax

Save([CopyToOriginal])

Description

The Save method saves the record to the database in two steps.

Check to see that it is safe to save this record to the database.
Either insert this record or update an existing record.

To accomplish the first step and determine that it is safe to save the record, this method uses similar logic to that used in the component processor when it saves a record. To do that a “select for update” SQL statement is executed. If, as a result of this statement, the record does not exist in the database, this method simply inserts the record into the database. All the processing that occurs for the insert method then occurs.

If the result of the “select for update” statement returns a record, the values of all the fields in the database record are compared to the original values of the record executing this method. If they are equal, indicating that no other user has updated the record, the record in the database is updated. All the processing that occurs for the update method then occurs. If the result of the above comparison fails, indicating that there has been an update of the database record in the meantime, perhaps by some other user, the save method fails and returns a false result.

For the update process to succeed, the record object must contain both original and changed values of the data. It is crucial to get data loaded into the record object correctly. To do this, do one of the following:

Derive the record object from the component buffers.
Derive the record object from a rowset filled using the Fill method.
Load the data using the record class SelectByKey and SelectByKeyEffdt methods specifying the optional Boolean parameter to be False.

See the note and example below.

Of course when you use Save to simply insert data you do not need load data into the record object this way.

Use this method when you are writing applications that do not use the facilities that come predelivered with the component processor and you must deal with issues of data contention.

For example, suppose you are writing an application that deals with course registration. You have to handle changing the number of students who are registered carefully if it is possible for more than one user to be registering for the same course at the same time. The normal way is to use the component processor to handle data contention by placing the record that deals with the number of students registering on some page. Then if two users try to update the same record one of them receives a message indicating that the page has been updated by another user.

If you write an application, outside the component processor, that relies on the record class to manage the number of students enrolled, it is not sufficient to use the record class Insert or Update methods to maintain data integrity. Suppose one user registers for the course and sees there are 10 other registrants. At the same time another user registers for the course and sees that there are also 10 registrants. Suppose the maximum is 11 students. Both users at this point believe they can register since at the point they accessed the data from the database there were only 10 students. So far, so good. The trouble comes when they save their registrations. If the application uses the update method, after simply adding one to the number of registrants, both updates will succeed indicating there are now 11 students in the course when in fact there are now 12. It is for cases such as these that the Save method applies since it guarantees that one of the save calls will fail. It is up to the application then to let the user know that while they were thinking about it someone else registered for the course and took the last spot.

The Save method is important to maintain data integrity. However, it can execute more slowly than saving within the component processor.

Since this method results in a database change, and does either insert or update processing, all the considerations and implications of using the Insert or Update methods apply. See the description of those methods for more detail.

The parameter CopyToOriginal indicates what action should occur on a successful save. If this parameter is true, the system copies the current changed buffers for the record into the original buffers for the record. This means that subsequent Saves, without reloading data from the database will run correctly. However if there are database specific updates to this record occurring outside of this application's control (such as, using database specific triggers,) it is always advisable to reload the data from the database.

The default value for this optional parameter is false, indicating that no update of the original buffers for this record occurs. If you are certain that there are no database updates occuring outside of your application's on save processing, you can specify this optional parameter to be true and save the overhead of having to reload the data for this record from the database. If you are unsure you should always reload the record data after calling the Save method.

Note: This method does not update fields marked as System maintained in the record definition in Application Designer.

Since this save is done outside the component processor save processing, no save processing PeopleCode that is associated with this record is executed.

Use of this method that results in an update, and requires that the data in the record object is such that both a before and after image of the data is kept. When the system loads data into the component buffers there is a concept of the “original data” (data loaded from the database) and “changed data” (data changed by the user or the application). This allows the system to determine when saving, whether the data has been changed by another user. If you use this method with record objects not derived from the component buffers you need to make sure that the data in the record object has both a before and after image otherwise the save method fails. Record objects derived from rowsets that have been populated using the Fill method will not produce an error. However if you load data into a record object using either the SelectByKey or SelectByKeyEffdt record class methods, you need to specify the CopyToOriginal parameter so the system will load the data into the original data buffers, not the changed data buffers. To do that specify the optional parameter to be False. See the example below.

Parameters

Field or Control	Definition
`CopyToOriginal`	Specify what action should occur on a successful save. This parameter takes a Boolean value: true, then the system copies the current changed buffers for the record into the original buffers for the record, false, the buffers are not copied. The default value is false.

Returns

The result is True on successful completion, False if there were no changed fields in the record or it was not safe to save this record (see above for details). Any other conditions cause termination.

Note: It is not possible to ignore the return code from the Save method in your PeopleCode.

Example

Suppose that KEYF1 and KEYF2 are the key fields of record definition MYRECORD, and that this record definition also contains the record field definitions MYRF3, MYRF4. The following code tries to save MYRECORD record in the database with KEYF1 set to "A", KEYF2 set to "B", setting MYRF3 to "X" and MYRF4 to "Y". This example works with a brand new record object and results in an insert if successful.

/* First -- create a brand new record */
Local record &REC;
&REC = CreateRecord(RECORD.MYRECORD);
&REC.KEYF1.Value = "A";
&REC.KEYF2.Value = "B";

/* Second -- update values as needed */
&REC.MYRF3.Value = "X";
&REC.MYRF4.Value = "Y";
/* Finally save it */
if &REC.Save() then
    /* handle the successful return */
else
    /* handle the unsuccessful return message to user? Try again? */
end-if;

This example works with an existing record and results in an update if successful.

/* First - create the record and get the data from the db */
Local record &REC;
&REC = CreateRecord(RECORD.MYRECORD);
&REC.KEYF1.Value = "A";
&REC.KEYF2.Value = "B";
&REC.SelectByKey(False); 
/* False retrieves data into the original, not changed buffers. */

/* Second - update values as needed */
&REC.MYRF3.Value = "X";
&REC.MYRF4.Value = "Y";
/* Finally save it */
if &REC.Save() then
    /* handle the successful return */
else
    /* handle the unsuccessful return - message to user? Try again? */
end-if;

Syntax

SearchClear()

Description

The SearchClear method clears the field values for all search keys for a record.

Considerations Using SearchClear and SearchDefault

The field property SearchDefault sets a field to its default value (if there is one) immediately after SearchInit PeopleCode finishes. SearchDefault overrides SearchClear. If you call SearchClear for a record, then use SearchDefault for a field, the field is set to its default value and the search key values for the rest of the record are cleared.

Parameters

None.

Returns

None.

Example

Local Record &REC;

&REC = GetRecord();
&REC.SearchClear();

Syntax

SelectByKey([UseChangedBuffers])

Description

The SelectByKey method uses the key field names of the record and their values to build and execute a Select SQL statement. The field values are then fetched from the database SQL table into the record object executing the method, and the Select statement is closed.

Note: You can't use this method in dynamic views.

If you don’t specify all the key fields for a record, those you exclude are added to the Where clause with the condition equal to a blank value. If not all keys are set and more than one row is retrieved, you won't receive an error and SelectByKey won’t fetch any data.

SelectByKey returns a single row of data. To fetch more than one row, use the SQL object.

For every record read by the SelectByKey method, if the set language is not the base language and the record has related language records, the SelectByKey method tries to do related language processing.

You can also select into a record using SQLExec and meta-SQL. For example, if you need to use SelectByKey with an effective date, you can use the meta-SQL %SelectByKeyEffDt in a SQLExec statement. In the following example, &RECOBJ is the name of a record created using the CreateRecord function.

SQLExec("%SelectByKeyEffDt(:1, :2)", &RECOBJ, %Date, &RECOBJ);

Parameters

Field or Control	Definition
`UseChangedBuffers`	Specify whether to retrieve the data into the changed or original buffers. The system keeps track of the original and changed values. This parameter takes a Boolean value: true, retrieve into the changed buffers, False, use the original buffers. The default value is true. is to retrieve the data into the changed buffers. To use this parameter with the Save method, it is important that data be loaded into the original buffers in order for the save logic to work. To do that specify a value of false for this parameter. See Save.

Field or Control

Definition

UseChangedBuffers

Specify whether to retrieve the data into the changed or original buffers. The system keeps track of the original and changed values. This parameter takes a Boolean value: true, retrieve into the changed buffers, False, use the original buffers. The default value is true. is to retrieve the data into the changed buffers.

To use this parameter with the Save method, it is important that data be loaded into the original buffers in order for the save logic to work. To do that specify a value of false for this parameter.

See Save.

Returns

The result is true on successful completion, false if the record was not found. Any other conditions cause termination.

If false is returned, the system resets the record values to their default values for scrolls that are not derived. If you do a manual insert afterwards (using the Insert method) you may insert a record with null keys.

Example

Suppose that KEYF1 and KEYF2 are the two key fields of record definition MYRECORD. The following code reads the database record that has KEYF1 equal to "A" and KEYF2 equal to "X" into the &REC record object:

Local record &REC;
&REC = CreateRecord(RECORD.MYRECORD);
&REC.KEYF1.Value = "A";
&REC.KEYF2.Value = "X";
&REC.SelectByKey();

The following example verifies if the method completes successfully before using the Insert method.

if not &Rec.SelectByKey() then

     /* Must duplicate this key field population before the Insert - else can get 'blank' row */

      &Rec.KEY1.Value = ...;
      &Rec.KEY2.Value = ....;
      ....

     &Rec.Insert();

end-if;

Syntax

SelectByKeyEffDt(Date[, UseChangedBuffers])

Description

Use the SelectKeyByEffDt to build and execute a SQL Select statement to get the current effective row based on an "as of date". The field values are then fetched from the database SQL table into the record object executing the method, and the Select statement is closed.

Note: You can't use this method in dynamic views.

SelectByKeyEffDt returns a single row of data. To fetch more than one row, use the SQL object.

For every record read by the SelectByKeyEffDt method, if the set language is not the base language and the record has related language records, the SelectByKeyEffDt method tries to do related language processing. The system assumes that both the base table and the related language table are effective-dated and that the effective-date keys are the same in each.

To use other keys, more than just the effective date, use the SelectByKey Record class method.

Parameters

Field or Control	Definition
`Date`	Specify the "as of" date you want to use as the effective date for the Select statement.
`UseChangedBuffer`	Specify whether to retrieve the data into the changed or original buffers. The system keeps track of the original and changed values. This parameter takes a Boolean value: true, retrieve into the changed buffers, False, use the original buffers. The default value is true. is to retrieve the data into the changed buffers. To use this parameter with the Save method, it is important that data be loaded into the original buffers in order for the save logic to work. To do that specify a value of false for this parameter. See Save.

Field or Control

Definition

Date

Specify the "as of" date you want to use as the effective date for the Select statement.

UseChangedBuffer

To use this parameter with the Save method, it is important that data be loaded into the original buffers in order for the save logic to work. To do that specify a value of false for this parameter.

See Save.

Returns

The result is True on successful completion, False if the record was not found. Any other conditions cause termination.

If false is returned, the system resets the record values to their default values for scrolls that are not derived. If you do a manul insert afterwards (using the Insert method) you may insert a record with null keys.

Example

Local Record &Rec;
Local any &Date;

&Date = %Date;
&Rec = CreateRecord(Record.COMPANY_TBL);
&Rec.COMPANY.Value = "CCB";

If &Rec.SelectByKeyEffDt(&Date) Then
   &Out = &Rec.DESCR.Value | " as of " | &Rec.EFFDT.Value | "->" | &Rec.STREET1.Value;
   WinMessage("Found this company: " | &Out);
Else
   WinMessage("Not there!");
End-If;

Syntax

SetDefault()

Description

SetDefault sets the value of every field in the record to a null value, or to a default, depending on the type of field.

If this method is used against data from the Component buffers, the next time default processing occurs, it is set to its default value: either a default specified in its record field definition or one set programmatically by PeopleCode located in a FieldDefault event. If neither of these defaults exist, the Component Processor leaves the field blank.
If this method is used with a field that isn't part of the data buffer (for example, a field in a record object instantiated with CreateRecord) the field is automatically set to its default value if one is set for the field, not for the record field. Any FieldDefault PeopleCode does not run on these types of fields. To set the default values for just one field, use the SetDefault field class method.

Blank numbers correspond to zero on the database. Blank characters correspond to a space on the database. Blank dates and long characters correspond to NULL on the database. SetDefault gives each field data type its proper value.

Parameters

None.

Returns

None.

Example

&CHARACTER.SetDefault();

Syntax

SetEditTable(%PromptField, RECORD.recordname)

Description

The SetEditTable method works with the ExecuteEdits method. It sets the value of a field on a record that has its prompt table defined as %PromptField value. %PromptField values are used to dynamically change the prompt record for a field.

There are several steps to setting up a field so that you can dynamically change its prompt table.

To set up a field with a dynamic prompt table:

Define a field in the DERIVED record called fieldname.
In the record definition for the field you want to have a dynamic prompt table, define the prompt table for the field as %PromptField, where PromptField is the name of the field you created in the DERIVED record.

Note: When you use SetEditTable, you don’t have to add a hidden field to the page.
Use SetEditTable to dynamically set the prompt table.

%PromptField is the name of the field on the DERIVED work record. RECORD.recordname is the name of the record to be used as the prompt table.

&REC.SetEditTable("%EDITTABLE1", Record.DEPARTMENT);
&REC.SetEditTable("%EDITTABLE2", Record.JOB_ID);
&REC.SetEditTable("%EDITTABLE3", Record.EMPL_DATA);
&REC.ExecuteEdits();

Every field on a record that has the prompt table field %EDITTABLE1 will have the same prompt table, that is, DEPARTMENT.

See ExecuteEdits, Understanding Record Definitions.

Considerations for SetEditTable and ExecuteEdits

The keys used to "select" the correct row in the prompt table record come only from the record object executing the method. All the keys from the component are not used. You may get unexpected results if not all the keys for the prompt table are filled in (or filled in correctly.)

Parameters

Field or Control	Definition
`%PromptField`	Specifies the name of the field in the DERIVED record that has been defined as the prompt table for a field in the record definition.
RECORD.`recordname`	Specifies the name of the record definition that contains the correct standard system edits to be performed for that field in the record.

Returns

None.

Example

/* To Set the Prompt Table */
&Der_EditRec = &TSKPRF_Det_Row.GetRecord(Record.DERIVED);
&Prompt_Editname = &Der_EditRec.EDITTABLE.Value;
&Prompt_Edittable = "Record." | &Prompt_Editname;
&TSKPRF_Det_Rec.SetEditTable("%EDITTABLE", @&Prompt_Edittable);

&Prompt_Editname2 = &Der_EditRec.EDITTABLE2.Value;
&Prompt_Edittable2 = "Record." | &Prompt_Editname2;
&TSKPRF_Det_Rec.SetEditTable("%EDITTABLE2", @&Prompt_Edittable2);

&Prompt_Editname3 = &Der_EditRec.EDITTABLE3.Value;
&Prompt_Edittable3 = "Record." | &Prompt_Editname3;
&TSKPRF_Det_Rec.SetEditTable("%EDITTABLE3", @&Prompt_Edittable3);

&Prompt_Editname4 = &Der_EditRec.EDITTABLE4.Value;
&Prompt_Edittable4 = "Record." | &Prompt_Editname4;
&TSKPRF_Det_Rec.SetEditTable("%EDITTABLE4", @&Prompt_Edittable4);

&Prompt_Editname5 = &Der_EditRec.EDITTABLE5.Value;
&Prompt_Edittable5 = "Record." | &Prompt_Editname5;
&TSKPRF_Det_Rec.SetEditTable("%EDITTABLE5", @&Prompt_Edittable5);

&Prompt_Editname6 = &Der_EditRec.EDITTABLE6.Value;
&Prompt_Edittable6 = "Record." | &Prompt_Editname6;
&TSKPRF_Det_Rec.SetEditTable("%EDITTABLE6", @&Prompt_Edittable6);
      
&TSKPRF_Det_Rec.ExecuteEdits(%Edit_Required + %Edit_PromptTable);

Syntax

Update([KeyRecord])

Description

The Update method uses the changed fields of the record and their values to build and execute an Update SQL statement, updating the SQL table. If you are updating the key fields of the record, you must supply a record object KeyRecord that contains the old values of the key record fields.

Because this method results in a database change, it can only be issued in the following events:

SavePreChange
WorkFlow
SavePostChange

If your application is repeating the same instruction many times, such as doing a million UPDATEs, use the SQL object with the BulkMode property set to True, rather than the record SQL methods.

For every record updated by the Update method, if the set language is not the base language and the record has related language records, the Update method tries to do related language processing.

Note: This method does not update fields marked as system maintained in Application Designer.

Parameters

Field or Control	Definition
`KeyRecord`	If you’re updating the key fields of the record, you must supply the old key field values in the record object `KeyRecord`.

Returns

The result is True on successful completion, False if the record was not found or (when updating the key fields) a duplicate record was found. Any other conditions cause termination.

Example

Suppose that KEYF1 and KEYF2 are the key fields of record definition MYRECORD, and that this record definition also contains the record field definitions MYRF3, MYRF4. The following code updates the MYRECORD record in the database with KEYF1 set to "A", KEYF2 set to "B", setting MYRF3 to "X" and MYRF4 to "Y":

Local record &REC;
&REC = CreateRecord(RECORD.MYRECORD);
&REC.KEYF1.Value = "A";
&REC.KEYF2.Value = "B";
&REC.MYRF3.Value = "X";
&REC.MYRF4.Value = "Y";
&REC.Update();

This code updates the MYRECORD record in the database with KEYF1 of "A" and KEYF2 of "B", setting KEYF2 to "C", MYRF3 to "M" and MYRF4 to "N":

Local record &REC1, &REC2;
&REC1 = CreateRecord(RECORD.MYRECORD);
&REC2 = CreateRecord(RECORD.MYRECORD);
&REC1.KEYF1.Value = "A";
&REC1.KEYF2.Value = "B";
&REC2.KEYF1.Value = "A";
&REC2.KEYF2.Value = "C";
&REC2.MYRF3.Value = "M";
&REC2.MYRF4.Value = "N";
&REC2.Update(&REC1);

Record Class Methods

CompareFields

Syntax

Description

Parameters

Returns

Example

CopyChangedFieldsTo

Syntax

Description

Parameters

Returns

Example

CopyFieldsTo

Syntax

Description

Parameters

Returns

Example

Delete

Syntax

Description

Parameters

Returns

Example

ExecuteEdits

Syntax

Description

Considerations for ExecuteEdits and SetEditTable

Considerations for ExecuteEdits and Numeric Fields

Parameters

Returns

Example

GetField

Syntax

Description

Parameters

Returns

Example

Insert

Syntax

Description

Related Links

Parameters

Returns

Example

Save

Syntax

Description

Related Links

Parameters

Returns

Example

SearchClear

Syntax

Description

Considerations Using SearchClear and SearchDefault

Parameters

Returns

Example

SelectByKey

Syntax

Description

Related Links

Parameters

Returns

Example

SelectByKeyEffDt

Syntax

Description

Parameters

Returns

Example

SetDefault

Syntax

Description

Parameters

Returns

Example

SetEditTable