Query Areas

Use

Query areas were created to allow you to fulfill varying requirements with SAP Query.

A query area contains a set of query objects (queries, InfoSets, and user groups) that are discrete and consistent.

You can differentiate between two different query areas, the global area and the standard area. Both query areas provide you with a full range SAP Query functions.

Global area

The query objects of the global area are cross-client objects. They are available across the system, that is, in all clients. Query objects in the global area are connected to the Workbench Organizer. They can be created and transported using the normal correction and transport procedures.

Transport is initiated automatically and no manual preparation is required. The global query area is therefore well suited for centrally developing queries meant for use and distribution throughout the system. All query objects delivered by SAP (from Release 4.0) are located in the global query area.
Standard area

In the standard query area, all query objects (queries, InfoSets, user groups) are created and managed specifically for each client. Standard area objects are not linked to the Workbench Organizer, that is they cannot be created and transported according to normal correction and transport procedures. The use of the standard area has its advantages when users want to develop queries in their clients (ad-hoc reports) that are not meant to be used in the system as a whole. Query objects can still be transported, however the transport process requires manual preparation and is not automatically initiated (export and import takes place using Query transport tools). For more information, see Transporting Standard Area Objects.

Both the global and the standard query areas contain discrete and consistent numbers of query objects. No relationships of any sort can exist between objects from different query areas. For example, you cannot create a query in the standard area using an InfoSet from the global area.

Note

Each query area can be viewed as a discrete namespace for query objects. This means that objects can exist in different query areas that have the same name but different meanings.

Global Area Naming Conventions

How to name queries, user groups, and InfoSets has already been discussed in the previous sections. When naming global area query objects, certain prefixes can be used.

Note

You may only use a particular prefix after first having purchased its corresponding license.

A prefix is composed of '/prefix/' and precedes the actual object name. The / symbols before and after the prefix name are actually part of the prefix. A prefix can contain up to 10 characters including the two / symbols.

Pay attention to the following guidelines:

InfoSet names can take the form '/prefix/InfoSet'.

The entire name of the InfoSet including prefix can contain up to 24 characters.
User group names can take the form '/prefix/user_group'.

The entire name of the user group including prefix can contain up to 12 characters.
Query names take the form 'query'.

Query names have no prefix of their own, instead they take the prefix of their user group. A query name can contain up to 14 characters.
Prefixes may only be used with InfoSets and user groups from the global area. The Workbench Organizer checks to see if prefixes are used correctly.

The individual query object maintenance transactions check the name syntax described above. You can only work using name prefixes with query objects in the global query area. This is significant because it is in this area that query objects from SAP are inserted at PUT if necessary. All query objects delivered by SAP have the prefix '/SAPQUERY/', which has been reserved for them.

Note

When using prefixes in the global area, ensure that objects whose names begin with a prefix belong to the development class with the same prefix. The Workbench Organizer checks to see if this condition has been fulfilled.

When creating queries for a user group whose prefix belongs to SAP, a business partner or another R/3 customer, you must pay special attention to the fact that queries 'inherit' their prefixes from their user groups. These kinds of user groups can in turn be transported into your system using a PUT or other transport method. These queries then belong to the objects found in the namespace determined by the user group's prefix.

If, for example, a query is created in the user group '/SAPQUERY/xx', then this query inherits the prefix '/SAPQUERY/'. It seems, therefore, that the query belongs to those objects delivered by SAP. This in turn could lead to the query being overwritten during the next transport. Therefore, it is recommended that no new queries be created in these user groups and that you use your own user groups when creating new queries.

Changing Query Areas

You can change query areas from each query object maintenance component by choosing Start of the navigation path Environment Next navigation step Query Areas End of the navigation path . A window appears containing both query areas and their long texts.

Use Choose to choose the query area that you want. If you choose to work in the global area, this is displayed on the initial screen of the maintenance component. In the standard area no such text is displayed. The same maintenance component functions are available in both query areas.

You can display technical information about a query area by choosing Information on the screen where you chose which query area you wanted to work in. A dialog box appears where a long text is displayed along with information about whether or not the objects are client specific or linked to the Workbench Organizer.

Assigning Development Classes in the Global Area

Due to the fact that query areas are linked to the Workbench Organizer, a development class must be designated when query objects are created. Query objects are entered into a correction request whenever they are created or changed.

In the global area, you can classify query objects as local objects (using a temporary development class, usually $TMP). (This is the same as creating a query object in the standard area). There are several conditions that you should pay attention to when designating or changing development classes:

All query objects in the global area have to be assigned to a development class (temporary development classes included). If the development class is not temporary, that is to say transportable, then the object must be entered in a correction request when it is being created or changed.
User groups and InfoSets can be assigned to any development class you want.
Queries can only be assigned to non-temporary development classes if their corresponding user groups and InfoSets are also assigned to non-temporary development classes. If, when you are creating a query, it is determined that either the InfoSet or user group assigned to that query is part of a temporary development class, then your query will automatically be assigned to development class $TMP. Whenever this happens, no dialog box asking you to determine a development class will appear.

Note

In order to simplify matters, it is recommended that you always assign user groups and InfoSets in the global area to transportable development classes. In this way, all queries can be assigned to any development class you want.

All query objects in the global area that are assigned to non-temporary development classes must be entered in a correction request when being created or changed. An exception occurs with customizing settings. Changes to the user/user group assignment or the InfoSet/user group assignment can be made without being entered in a correction request. Transports made using the Workbench Organizer do include InfoSets' user group assignments, not however users' user group assignments.

You can change development classes in the various query object maintenance components by choosing Start of the navigation path Query Next navigation step More Functions Change Development Class InfoSet More Functions Change Development Class End of the navigation path or User Group Change Development Class . However, in accordance with the rules for assigning development classes formulated above, the following restrictions apply:

Changing a user group from a non-temporary development class to a temporary development class only makes sense if all of the user group's queries are assigned to a temporary development class.
Changing an InfoSet from a non-temporary development class to a temporary development class only makes sense if all of the InfoSet's queries are assigned to a temporary development class.
Changing queries from a temporary development class to a transportable development class only makes sense if the InfoSet areas and user groups they are assigned to are in a transportable development class themselves.

The function Change Development Class checks to see if you are allowed to change an object's development class and displays a warning if this is not possible. You may then change the development class.

Note

For technical reasons it is possible to make changes that conflict with the restrictions listed above. Therefore the system checks automatically to see if all changes made are acceptable. If a conflicting change has been made, a warning is displayed asking you to reconsider the change. If this were not the case, you would run the risk of having inconsistent datasets in all receiving systems after transport.

You can no longer change a development class when an object belongs to a transportable development class and has already been transported. This means that all development class changes described above must be made prior to transporting the object.

A development class change may also be necessary after a query object has been renamed. You must also ensure that the development classes of user groups and InfoSets that have been renamed still lie within the accepted name spaces for the new names. In this case it is advisable to choose an appropriate development class when you are renaming the object. With user groups the individual queries within the user group must also be assigned new development classes.

Renaming InfoSets and User Groups in the Global Area

When using the function Rename with InfoSets and user groups be aware of the fact that in addition to the InfoSet or user group, all dependent queries must also be renamed. If several InfoSets or user groups have been renamed, a series of queries must be included in a correction request in addition to the InfoSets and user groups. The renaming process is only actually finished when all objects necessary have been entered into a correction request.

Copying Query Objects between Different Query Areas

In order to copy query objects from one query area to another a special procedure must be followed to ensure that the datasets of each query area remain intact and consistent. During transfer you must check to see that the object being transferred can be inserted in the new dataset without upsetting the consistency of the latter. If you think of the global area as a single client, then the whole copying process, from the standard area to the global area and vice versa, corresponds to object transport from one client to the next. Thus, you copy query objects from one query area to the next in much the same manner as you copy objects within the standard area. For more information, Transporting Query Objects.

Note

Only those users in possession of the necessary transport authorization (InfoSet and user group maintenance authorization) can copy query objects from one query area to another.

Caution

If one or more query objects are moved from the standard area to the global area (or from the global area to the standard area), all relationships between the original and the copy are lost; two objects that are completely independent of each other are created. You should therefore avoid copying an object from the standard area to the global area just for the purpose of a simpler transport. If an object was first developed in the standard area and is now to be transported from the global area, it certainly makes sense then only to edit the object in the global area. It might be useful to delete the original object from the standard area in order to avoid misunderstandings.

Global Area Query Variants

If you want to transport query variants within the global area, these variants must be created as system variants. System variant names begin with either SAP& or CUS&. Other kinds of variants cannot be transported. (See also the variant documentation available on the initial variant maintenance screen).