These general limitations apply to cube deployment:
When loading data from an Essbase model containing a dimension created from a Calendar hierarchy, these limitations apply:
Text file data sources are not supported.
Essbase Studio Server must be run in streaming mode (described in server.essbase.streamingCubeBuilding).
In the “Load data options” group, selecting the “Overwrite existing data” option is not allowed.
If you add data load bindings to a cube schema from which an Essbase model was created, the cube schema and model will be out of sync. If you deploy from the existing Essbase model, the model does not pick up the new data load bindings, resulting in invalid deployment results. To deploy a cube using the new data load bindings, you must create a new Essbase model and deploy from the new model.
Incremental builds for XOLAP-enabled models are not supported.
If you are deploying from an Essbase model that is enabled for XOLAP, it is highly recommended that you use a new application and database name; or use the Delete all members first option to deploy over an existing XOLAP application.
You cannot deploy an XOLAP-enabled Essbase model that is based on an Oracle BI EE data source.
In nonstreaming mode (server.essbase.streamingCubeBuilding=false in server.properties), Essbase Studio can deploy cubes only from Oracle BI EE data sources version 10.1.3.4 or later. Cubes may be deployed from an earlier version of Oracle Business Intelligence Enterprise Edition, 10.1.3.3, only if the server.essbase.streamingCubeBuilding property is set to streaming (server.essbase.streamingCubeBuilding=true).
See server.essbase.streamingCubeBuilding for information on this property.
IBM DB2: A limitation in IBM DB2 handling of the LONG VARCHAR data type in a select DISTINCT statement causes cube deployment to fail. To avoid this failure, set server.essbase.disableDistinct to true.
See server.essbase.disableDistinct for information on setting this property.