Select Clause

Syntax

You must include a NAME_PATTERN when using the Select clause (and therefore cannot use a modified after DATE clause with it). For example:

list attribute mx* select type;

The result would be a list of all attributes beginning with “mx,” showing the name and type.

Select commands let you view a listing of the field names that make up the business object definition. Each field name is associated with a printable value. By selecting and listing the field names that you want, you can create a subset of the object’s contents and print only that subset. The system attempts to produce output for each Select clause input, even if the object does not have a value for it. If this is the case, an empty field is output.

Select can be used on its own or as a clause of the print businessobject and expand businessobject commands (for more information, see Expand Business Object), and in query where clauses (for more information, see Select Clauses in Queries). When used as its own statement, the items it lists are tagged for a subsequent print or expand statement.

Using Select and Related Clauses

Frequently, implementation code creates or modifies a businessobject or connection and then immediately needs to fetch new information from it. The select modifier is available so that data can be retrieved as output from the creation (including minorrevise and copy) or modification command itself, removing the necessity to make another, separate server call to get it, thereby improving performance. In the case of add/modify businessobject, the specified selects are applied to the businessobject being created/modified. The output produced is identical to a corresponding print bus command.

For more information, see Select Commands.

If these selects are used within a user-defined transaction, they will return data representing the current uncommitted form of the object/connection. The data is collected and returned after all triggers associated with the command have been executed, unless a transaction is active and a trigger is marked deferred, since in this case, the trigger is not executed until the transaction is committed, as shown below:

1) Larger transaction is started with any number of commands before the add/modify/connect command with the trigger.
    2) add/modify/connect transaction is started.
        3) Normal processing of access checking occurs.
        4) If it exists, the Check Trigger is fired.
        5) If Check blocks, then transaction aborts.
           If not, the Override Trigger is fired if it exists.
    6) The Event transaction is then committed regardless of an override or normal activity.
    7) If the Event Trigger has a non-deferred Action Program, it is executed.
    8) If the add/modify/connect command included a Select clause, the data is collected
       and returned at this point, even though the creation/modification has not been committed.
9) The larger transaction is committed if all activities and triggers succeed.
10) Finally, if the larger transaction successfully commits, and there is a deferred Action 
    Program, it is now triggered. If the larger transaction aborts, deferred programs are not executed.

Presumably, work would be done using the selected and returned data, between steps 8 and 9 above.

All Add Businessobject clauses provide information about the business object being defined. Only the Policy clause is required. The next sections describe each Add Businessobject clause.