Dividing a MultiProvider Query into
Sub-Queries 
Use
A query based on a MultiProvider is divided internally into sub-queries. A sub-query is generated for each InfoProvider associated with the MultiProvider.
Functions
The division of a MultiProvider query into sub-queries can be very complex. If you have defined a query for a MultiProvider and want to display how the query has been sub-divided, you need to call up transaction RSRT. This can be a useful step if your query does not behave as expected.
To observe how the query is divided, proceed as follows:
Use RSRT to execute the query with the Execute + Debug option. Choose the MultiProvider Explain option. The upper area of the screen, on which the query result is displayed, contains messages on how the query has been divided. The following messages can appear:
· DBMAN 133: There is a mapping rule that maps a characteristic (or navigation attribute) in the MultiProvider to a characteristic (or navigation attribute) of the same type (but not the same name) in the specified InfoProvider.
· DBMAN 134: The query contains a general restriction on the specified characteristic (or navigation attribute). This is not available in the specified InfoProvider. This is probably the reason why the sub-query is omitted from this InfoProvider.
· DBMAN 135: The specified key figure is either not available in the specified InfoProvider or it has not been selected for the MultiProvider. As a result, the sub-query does not read any values for this key figure.
· DBMAN 136: The sub-query for the selected InfoProvider has been excluded. The reasons for this are found in the preceding messages.
· DBMAN 137: A characteristic (or navigation attribute) is not available in the specified InfoProvider. For this reason, all the conditions in the same query column are irrelevant, and are not considered in the sub-query.
· DBMAN 138: All the conditions have been deleted for all the query columns (see DBMAN 137). This is because they could not be filled from the specified InfoProvider. Access to these key figures has therefore been excluded.
· DBMAN 139: The query only contains key figures that do not appear in the specified InfoProvider. Access to these key figures has therefore been excluded.
· DBMAN 140: A characteristic is set constantly at a particular value for an InfoProvider. This condition is not consistent with a condition contained in the MultiProvider query. As a result, access to the specified InfoProvider was excluded.
· DBMAN 141: This message describes a query restriction, to which a reference was made in a previous message. It contains information about
- the InfoCube or InfoProvider in question
- the query column (FEMS)
- whether the condition is inclusive (I) or exclusive (E)
- the characteristic (or navigation attribute) involved
- the relational operator
- and, if applicable, the operands of the condition
· DBMAN 144: This message describes a situation in which a restriction on characteristic A in the MultiProvider can apply to characteristic B in the specified InfoProvider, since a restriction (of the same level) already exists for characteristic B. The specified InfoProvider reads the data without this restriction. This restriction is processed subsequently by the BW OLAP processor.
· DBMAN 145: The specified InfoObject is interpreted as a real key figure for the specified InfoProvider. This can be relevant for a MultiProvider query when all other key figures in the query are not available in this InfoProvider and the sub-query would need to be left out (see DBMAN 139). In this case, this option is not available.
· DBMAN 146: When the MultiProvider query was processed in parallel, the interim result that was produced was too large for the system to handle, and the parallel processing was terminated. The query was restarted and processed in sequence. The problem did not reoccur, because with sequential loading the interim results are split into packages.
See Processing Sub-Queries in Parallel versus Sequential Processing.