$TEST_MODE_COMPONENTS

Allow the most recently compiled component to be instantiated in a running application.

$TEST_MODE_COMPONENTS

Defaults

Assignment file:

Any application assignment file

Section:

[SETTINGS]

Default value:

None

Description

$TEST_MODE_COMPONENTS enables Uniface to use the most up-to-date component when an application is running. This means that if a component is changed in the Development Environment and is compiled while the application it belongs to is running, the new component file (.frm, .rpt, or .svc) can immediately be used without needing to restart the application. However, Uniface continues using the old component descriptor until all instances of the component have been closed. The next instantiation of the component uses the new descriptor. $TEST_MODE_COMPONENTS accomplishes this by effecting the Drop Component from Memory property. Also, Uniface closes and reopens the URR file each time it needs a descriptor.

Note:   If you use $TEST_MODE_COMPONENTS, your application will use uana.urr, not udesc.urr.
Note:  If you use xmlload in combination with $TEST_MODE_COMPONENTS, it can happen that additional ‘Field not found’ warnings (visible in the message frame) are issued, which might significantly increase Uniface’s memory usage.

This setting works seamlessly for components that have not had any interface changes. However, with components that have had changes to their interface, such as a change in the data type of an operation’s parameter, the addition of a new operation, or the removal of a parameter, this functionality causes a mismatching unique ID error (-51 in $status) in several situations which prevents the component from being instantiated. The following sections describe how to avoid these errors.

Instantiating components that have had an interface change

When a component has an interface change, a new unique ID is generated. This causes an error upon instantiation of the new version of the component because the unique ID on the signature is compiled into the component file, but the unique ID for the component in the URR does not change. To avoid this error, you must do one of the following:

  • Use the Development Environment to generate a new uana.urr so that the URR file has the most recent descriptor.

  • Use $SEARCH_DESCRIPTOR= DBMS_FIRST to ensure that the new descriptor ID is retrieved from ULANA.DICT. ULANA.DICT has the most up-to-date descriptor, and therefore the most up-to-date unique ID.

Instantiating a new component version without closing existing instantiations

If you are using $CHECK_SIGNATURE_ID (to enable checking of signature ID when activating components), an error occurs (-51) in $status) if you instantiate a new version of a component whose unique ID has changed (due to interface changes) before you have closed all the existing component instances. This occurs because Uniface detects a mismatch between the component ID on the file and that of the old descriptor. To avoid this error without closing all of the existing component instances, you must remove $CHECK_SIGNATURE_ID.

Instantiating a component with the Keep data in memory property on

A mismatching unique ID error (-51 in $status) is caused when a component has the Keep data in memory property on , you are using $CHECK_SIGNATURE_ID, and all of the following steps are taken:

  1. The component is instantiated and then deleted (using deleteinstance).

  2. Component interface is changed

  3. Component is recompiled

  4. URR file is rebuilt (or ULANA is used instead, using the $SEARCH_DESCRIPTOR = DBMS_FIRST assignment setting)

  5. The instance of the component which was deleted in step 1 is reopened.

The error occurs because the application will continue using the old component file (due to the Keep data in memory property), but will use the new component descriptor (which has a new unique ID). If a new instance is created, there is no error because both the new component file and the new descriptor are used. To avoid the error, remove $CHECK_SIGNATURE_ID.