Query Areas
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 standard area and the global area. Both query areas provide you with a full range of SAP Query functions.
In the standard query area, all query objects (queries, InfoSets, user groups) are created and managed specifically for each client. Query objects are not attached to the Workbench Organizer, this means that they cannot be created and transported according to standard correction and transport procedures. This is a big advantage for end users that want to develop queries (ad-hoc reports) in their own client that are not meant for use in the rest of the system. 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 further information, see
Query objects in the global area are cross-client, that is they are available throughout the whole system and 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.
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.
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.
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:
The entire name of the InfoSet including prefix can contain up to 24 characters.
The entire name of the user group including prefix can contain up to 12 characters.
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.
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.
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.
Changing Query Areas
You can change query areas from each query object maintenance component by choosing Environment
® Query areas. 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:
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 like assigning users to user groups and InfoSets to user groups can be made without having to be 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 either Query
® More functions ® Change development class, InfoSet ® More functions ® Change development class or User group ® Change development class. However, in accordance with the rules for assigning development classes formulated above, the following restrictions apply: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.
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.
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.
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. (Please see also the variant documentation available on the initial variant maintenance screen).