If you activate NLS(Near-Line Storage) for providers used in Multiproviders (or Compositeproviders), the query might terminate with the error message DBMAN 309. When NLS is active,technically the query accesses NLS (a seperate supquery) as if there was a virtual provider containing the archived data. Since NLS does not support navigation attributes (except SDA on HANA, see note 2156717), it is required that the basis characteristic of an navigation attribute (used in the query) is requested from NLS. Hence, a corresponding mapping (identification, assignment) is needed. In case it does not exist, the system displays the error message DBMAN 309.
We discuss this in the following with the help of a simple example.
Our sample Multiprovider has only two cubes, for one with the technical name STPEDBIF2, NLS is active. The infoobject 0COUNTRY of the Multiprovider is mapped with the navigation attribute STPE_C1__0COUNTRY. Important is now the fact that the basis characteristic STPE_C1 is not part of the multiprovider (and hence also no mapping)!
As long as the query does not try to access the NLS, there is no problem at all. But if the corresponding query property is changed the query terminates:
In RSRT the following error messages are displayed:
In order to resolve this problem you need to change the definition of the multiprovider. It is required to define a mapping relation between the Infoobject STPE_C1 of the partprovider STPEDBIF2 and an Infoobject of the Multiprovider(se also the long text of the error message DBMAN 309). Thje simplest way to overcome this termination is probably to add STPE_C1 to the Multiprovider and then assign it to the Infoobject of the partprovider (for other possibilities see also DBMAN 309):
With this definition the termination DBMAN 309 does not occur!
Very helpful article. Thanks a lot!
But could anybody tell me why the Multiprovider Check does not show an error message for that issue?
My Settings in "Extras - Compounding Consistency" is:
Nevertheless I don't get any error message before executing the query (BW 7.40 SP 13).
From my POV this is definitely a bug and not a feature!
the checks regarding compounding inconsistencies only take into account characteristics and navigation attributes which are compounded. The mappings of 'father' and 'child' infoobjects are checked(see e.g. note 920416). So, when the navigation attribute is not compounded as in the simple example above, there can't be a so called CMP problem. The BRAIN 306 error is about the mapping of an navigation attribute (e.g. A__B) and its 'basis' characteristic (A). It can only be an issue when a partprovider has archived data and when the query accesses NLS and uses the navigation attribute. Since it strongly depends on the query definition (and navigation state) there is no general warning during activation of the multiprovider.
best regards, Peter
Thanks for Explanation. Obviously I misunderstood what the extra setting does.
It sounds reasonable, however from a developer's point of view SAP should implement a solution on activation via separate warning message if an underlying Dataprovider has an active DAP. Otherwise this problem occurs during query execution, and it took me quite a while to find out the root cause! Especially since the field stated in the error message is not even contained in the Multi, but instead a reference characteristic of that named had a missing mapping. This is quite bad.
Thanks for understanding, Martin