CubeGroup维度变动后，上下级关系错误【急，在线等】

目前的测试结果是：
自cube保留也没有什么效果，但是我发现我把上次刷新过程中生成的添加Categories之后的那个mdl当做本次刷新的原始mdl文件时，显示的列表就正常了。。。我之前每次刷新都用的原始的mdl，啥都没有添加的那个。。。

一会儿再测试下 Unique+move的情况。如果上下级关系有变动，只能通过这个方法来解决吧。~收起

完全同意6#楼，对cubegroup，每次生成子cube的时候会更新每个子cube的维度树结构，“每次产生的子cube保留当前目录下，不能清理。上传服务器也必须完整上传”收起

    对的，不能移走所有的子Cube。收起

回复 6# wengr


    首先谢谢您的回答。我的理解是：每次刷新一个月的子cube时，其他历史的子cube是转移走的。所以导致在刷新当前月份的子cube时，程序无法检查历史子cube的维度树状结构，可能会导致问题。不知道我理解的是否正确。目前我们这边确实这样做的。

另外，我现在做的测试都是在单台机器上做的，至手工增添一个科目，就导致了很大的错误。

我先把历史Cube拷回来，在重新刷新试试看。收起

回复 5# anda


    去掉了，还是不行哦。。。。:'(收起

如果MDL模型设计为CubeGroup模式，你的可变动维度就不能设置Unique+Move属性。

我没有猜错的话，你在每次运行按月生成的cube时，当前生成的cube有三个文件，其中一个文件夹是子cube目录，而你只有一个真正的cube文件，就是你当前运行的cube。通过生成好的Cube文件再发布到一个服务器子cube集中，理论是没有错，但时间长了，维度信息是不断变化过程中，导致前后子cube的维度树差异很大，在做分析时，单独对于某个时间点进行分析是不会出问题，当连续时间+可变维度时，问题就来了，也就会出现你报表的情况，因为报表是固定的格式，虽然是有条件选项，也就类似多维分析的维度组合。

解决这个问题的办法：去掉Unique+Move属性，生成子Cube目录下必须是所有存在的，可以单独打开的子cube，而不是生成完毕之后的当前一个子Cube。因MDL模型在每次生成子cube时，要检查源数据结构与历史维度树的校验，此时模型要检查所有生成后的历史子cube目录树结构，如果发现有维度变化，历史的子cube没有改变维度逻辑关系，校验机制会提示错误。
出现以上问题，建议定期全量刷新Cube，每次产生的子cube保留当前目录下，不能清理。上传服务器也必须完整上传收起

    恩  试试看然后看看结果如何巴收起

恩。。我在测试下其他的情况，吧move去掉试试~收起

估计可能是你这个move的问题，我们设的都是unique，没出现过这种问题。收起

在想是不是还有其他关联条件？收起