Bind Variables (User, System Administrator, and Flexfields Help)


	Previous	Next		Contents	Index	Navigation	Glossary	Library

Bind Variables

You can put special arguments (bind variables) in your WHERE clause that allow you to base your values on other values. These bind variables include :block.field, :$PROFILES$.Option_name, or :$FLEX$.Value_set_name, You may not use bind variables in the Value Column or Hidden ID Column fields (where you would normally specify a column name). You may use bind variables in the Description Column and Additional Columns fields.

Note that a bind variable, by default, is required; that is, it must have a value for the statement, expression, or user exit which uses it to have meaning.A bind variable can be made optional by using the :NULL suffix; so that if the bind variable is NULL, the segment/parameter using it will be disabled, and its required property (if enabled) will be ignored. The :NULL suffix is discussed at the end of this section.

:$FLEX$.Value_ Set_Name

Value_Set_Name is the name of either the value set for a prior segment, or the segment name of a prior segment in the same flexfield or parameter window that you want your validation table-based values to depend on. When you define your flexfield structure or report parameter window, you define the segment or parameter that uses value set Value_Set_Name to have a lower sequence number than the segment that uses your validation table-based value set. The $FLEX$ mechanism uses the "closest" prior segment with either a matching value set name or segment name (it looks for the value set name first, and uses the segment name second if there are no matching value set names).

Value_Set_Name is case-sensitive, so you must ensure that the name you specify here exactly matches the value set name you define in the Define Value Set form. Note that you can only use letters, numbers, and underscores (_) in your value set names if you want to use them with a :$FLEX$.Value_Set_Name clause. You cannot use quotes, spaces, or other special characters in these value set names, so you should be careful to define your value sets with names that do not contain spaces, quotes, or other special characters.

You can specify more than one :$FLEX$.Value_Set_Name in a single WHERE clause, thereby creating a segment whose list of possible values depends upon more than one previous segment.

When you specify :$FLEX$.Value_Set_Name, your flexfield segment or report parameter defaults to always use the hidden ID column (of the previous value set) to compare with your WHERE clause. The end user would never see the hidden ID value, however. If you do not specify a hidden ID column, your segment defaults to use the value in the value column instead.

When you specify :$FLEX$.Value_Set_Name, you can also explicitly choose which column for which you want :$FLEX$.Value_Set_Name to return a value. You do this by specifying :$FLEX$.Value_Set_Name.OUTPUT, where OUTPUT can be ID, VALUE, or MEANING (to return the value of the description column).

When you specify your validation table value sets, you can also use an INTO clause in the Additional Columns field (after your entire list of columns and aliases) to put the value into a variable you use with :$FLEX$.segment_name.OUTPUT, where OUTPUT is a name you choose. You can then retrieve that value using :$FLEX$.segment_name.OUTPUT (where OUTPUT is the same name) from another segment's value set WHERE clause. You cannot use OUTPUT to put a value directly into a field, but a value that a flexfield segment retrieves may be put into a hidden form field that the segment corresponds to once the popup window closes. If you do not specify an INTO clause in your Additional Columns field, your value is not placed anywhere other than being displayed in the list of values (it goes INTO NULL).

Attention: If you are using flexfields server-side validation, you cannot use the INTO clause for your value set. You must either remove your INTO clauses or turn off flexfields server-side validation using the profile option Flexfields:Validate on Server.

See:

Flexfields:Validate on Server

:block.field

:block.field is the SQL*Forms/Oracle Forms name of a field on the form where your descriptive flexfield appears. You can use this argument to make your value set context-sensitive to a field on a form. While this is somewhat similar to using a reference field with a descriptive flexfield, using a reference field with a descriptive flexfield provides a choice between different structures of context-sensitive segments (and indirectly, their value sets). Using this :block.field argument, however, gives you the same segments that would normally appear, but changes the contents of the value set attached to the segment depending on what appears in your :block.field. In some cases, you may wish to use a :block.field value set instead of a descriptive flexfield reference field with many different context-sensitive structures.

Note that if you use this argument, you must have the same :block.field on every form where a value set based on this validation table could be used. For example, if the same flexfield appears on seven forms, then all seven forms must have this block.field. Similarly, if you share your value set among more than one flexfield, then all forms that use any of those flexfields must have this block.field. Though it is possible to use this argument for a key flexfield segment or report parameter, the same restriction applies; that is, you must have the same block.field wherever the value set can be used.

Warning: The :block.field mechanism is present for backward compatibility only. Value sets that use this mechanism will not be compatible with a future release of Oracle Applications. If you are using flexfields server-side validation, you cannot use form field references (:block.field). You must either remove your field references or turn off flexfields server-side validation using the profile option Flexfields:Validate on Server.

See:

Flexfields:Validate on Server

:$PROFILES$. profile_option_ name

Profile_option_name is the internal option name of a user profile option such as CONC_COPIES (for Concurrent:Report Copies) or GL_SET_OF_BKS_ID. For example, you could define your WHERE clause as:

			WHERE SET_OF_BOOKS_ID = 
			:$PROFILES$.GL_SET_OF_BKS_ID

See: Overview of Setting User Profiles

:NULL suffix

Use the :NULL suffix to make your bind variable optional, that is, allow null values. Instead of :block.field, :$PROFILES$.Option_name, or :$FLEX$.Value_set_name, you would use :block.field:NULL, $PROFILES$.Option_name:NULL, or :$Flex$.Value_set_name:NULL, respectively. For example, if your value set name is Car_Maker_Name_Value_Set, you would use :$FLEX$.Car_Maker_Name_Value_Set:NULL.

See also: Example of $FLEX$ Syntax: page - 42

Special Treatment for WHERE Clauses