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!