Properties shared between overlays and origin objects

Overlay objects have the following types of attributes or properties:

  • Properties that are independent and can have different values in the origin and overlay objects. This includes most properties.
  • Properties that are inherited from the origin object and that cannot be modified by the overlay object.
     If such a property is changed on the origin object, it is overwritten to the overlay as well. For example, changing the name of the origin object causes the overlay object to be renamed.
  • Properties that are shared with origin objects.
     These are properties that can be set in the overlay and that will affect the overlay and the origin object. Generally, these properties are shared because the overlay and origin object for forms share the same database table. For example, adding an index in an overlay causes the database to create an index, and that index affects data for the overlay and the origin form.

Any property that is not listed in the following tables can be overwritten.

The following table describes the properties that are inherited from an origin object regardless of the granular component overlay types.  You cannot prevent inheritance of these elements with overlays, regardless of the type of overlay on its granular components. When the inherited properties are modified in the origin object, the corresponding values are modified in the overlay object.

Properties inherited from origin object

Property inherited from origin object

Permitted modification on overlay object

Object name

You cannot change in an overlay.

Unique indexes

You cannot change in an overlay.

FTS
Weighted relevancy fields for multi-form search

  • Title
  • Environment
  • Keywords

If these values are set in the base, they are inherited from the base. You cannot change the values in the overlay form. If the values are modified in the base form, they are inherited in the overlay form. See Configuring forms for multiple-form FTS.

Audit and archiving

If set in the base, you cannot modify in an overlay. See How-auditing-and-archiving-work-with-overlays-and-custom-objects.

Form application owner

You cannot change in an overlay.

Join form information

If you overlay a member form's field and you overlay the same field on the join form, you will see changes made in the member form overlay in the join.

Generally, you cannot modify the inherited information for a join form or its fields.  An exception is that you can change permissions on a join form and permissions on its Request ID field.

Vendor form plug-in

You cannot change the server plug-in that is used to supply data for the vendor form.

View form database table

You cannot change the source table used to supply data for the view form.

An overlay of a form has data in the same tables as the origin form.  An overlay of a field has data in the same columns as the origin field.  Some changes to data can cause extra columns to be created in a table, or can affect what is written in the columns. The following table explains these changes.

Impact of modifying shared properties on the database tables

Property

Permitted modification on overlay

Impact on database table

Enum or Selection field

There are no restrictions on changing the properties of an Enum field. If you add new values, the data is stored and available through the overlay object and the origin object, but the origin object cannot display a label for the enum field. If the same value is later added to the origin object through an upgrade, you must reconcile the difference.

Enumerated values are stored in a column that is visible to the origin and overlay objects.

FTS and multiform search properties

Most FTS properties on origin and overlay objects are to be considered cumulative. The following multiform search properties cannot be cumulative (exceptions):

  • For fields—Category Name search category.
  • For forms, the following search categories:
    • Environment
    • Keywords
    • Title
      For these exceptions, the BMC Remedy AR System server behavior is as follows:
  • If these attributes are set on the overlaid form, you cannot change them on the overlay. Overlay forms only inherit these attribute values.
  • If these attributes are not set on the origin form, you can change them on the overlay. Their values are available for both the origin and overlay forms at runtime.
  • If any changes to these attributes are made on the origin form (for example, through an upgrade), the AR System server reflects the same changes on the overlay form by overwriting these attribute values.

There is no impact on the database, but effects are seen in the origin object and the overlay.

Functional currency for a Currency field

  • Adding functional currency
  • Deleting functional currency

For each functional currency that you add to a Currency field, a column is added in the database. The number of columns in the database is a sum of the number of functional currencies added to the origin object and its overlay.

For example, if the origin object has two functional currencies (INR and USD) but on its overlay you removed USD and added EUR, the database contains three columns: INR, USD, and EUR. If you removed a functional currency from both the origin object and the overlay, the corresponding column is deleted from the database.

Length of a Character field

Changing the field length

Lengths of the origin Character field and its overlay are compared to find the maximum of the two. Actual length of the corresponding column in the main data table is set to this value. For example, if the origin field's length is 100 bytes and the overlay field's length is 200 bytes, the size of the corresponding database column is 200 bytes.

Switching from a CLOB to a shorter database length can cause loss of data because they are different database types.

Next request ID block size

You can set this property independently on the overlaid and overlay objects.

At runtime, the maximum of the next ID block size of the overlaid and overlay object is used.

Non-unique index on a form

  • Adding a new non-unique index
  • Changing a non-unique index
  • Deleting a non-unique index

Actual indexes on the main data table reflect a combination of the indexes on the origin object and its overlay.

Status History

By default, Status History is enabled for a form. When Status History is disabled, the AR System server removes any current status history entries. Status History must be disabled on both the origin and overlay objects for it to be removed.

  • Enabling status history
  • Disabling status history

If Status History is enabled on one of the origin and overlay objects and is disabled on the other, the status history will only be stored on the object where it is enabled.

Archive and audit

If set in the origin form, data for both the origin and the overlay are archived and audited to the same place.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*