Leveraging replicated partitions can be a useful method of transferring data between two cubes, but certainly does not come without its quirks.  The following blog will provide you with the steps needed to work around a rare but show-stopping error message that you can run into while managing an environment that utilizes replicated partitions.

When managing a design that introduces replicated partitioning, I prefer to execute MaxL statements which create, refresh, and then drop the replicated partitions each time the transfer of data is needed.  In my instance, I’m doing this because metadata changes require partition changes and once the partition definition has been refreshed there is no benefit to leave the unused object out in the environment.  Every so often, I run into the following error message when attempting to create a partition definition:

“Object <DatabaseName> does not exist”

The database mentioned is running and data can be retrieved from it as well, so obviously the literal explanation of this error message is not valid.

Could this be related to a partition not being successfully dropped?  On the surface it would appear the answer would be no, as when I look in EAS there are no partitions accessible under the database referenced in the error message.

Essbase partitioning quirks - EAS

(click to enlarge)

However, when I look in the corresponding database directory on the Essbase server, I find a file with a “.ddb” file extension (this is the extension for partition files).

Partitioning quirks - Essbase server

(click to enlarge)

This is surprising as I executed a drop partition MaxL statement which completed successfully and I am also unable to locate the partition in EAS.

By manually deleting the partition file in the database directory and re-attempting to execute the create partition command, it works!  I am now able to create a partition on the database mentioned in the error message above without any issues, business as usual.

It seems that a corrupted partition file was essentially “stuck” out on the Essbase server for this database and the only way to move forward is to manually delete the file.  I decided to share this information via a blog post in hopes to save others the time and energy spent on investigating this error message.

Again, leveraging replicated partitions can be a great way to transfer data given a proper use case, but there can be quirks you may run into where the error message provided is not very informative.

Experiencing partition issues? Have more questions? We can help: