昨天被Services Team提回来一个问题，说
我们的产品在获取成员的子成员数量时，不时会出现数不准的问题。结果用他们提供的Cube反复试验，最终发现这个问题原来是由于Cube的Dimension存储格式是Rolap引起的，详细错误复现和原因大概是这样的。
当我们把一个Cube的Dimension的存储格式设置为了Rolap后，在" 第一次"访问这个Cube时，取回来的第一个Member(一般是All Level的那个自动Aggregate)的ChildCount始终是1000。这个第一次有个限制，是Cube冷查询的第一次，就是说Cube被处理后，还从来没有被访问过。因为一旦这个Rolap Cube被访问过后，Dimension就动态的刷新了，这时取到的ChildCount就是实际的正确数量值了。
通过跟踪Adomd.net(8.0)的Member类的ChildCount属性，我们可以清楚地看到，这个1000其实就是一个在系统未取到真实的ChildCount时的一个默认数值：
// return ( long) ( Convert. ToInt32( AdomdUtils. GetProperty( row2, "DisplayInfo"), CultureInfo. InvariantCulture) & 0xffff);
当我们把一个Cube的Dimension的存储格式设置为了Rolap后，在" 第一次"访问这个Cube时，取回来的第一个Member(一般是All Level的那个自动Aggregate)的ChildCount始终是1000。这个第一次有个限制，是Cube冷查询的第一次，就是说Cube被处理后，还从来没有被访问过。因为一旦这个Rolap Cube被访问过后，Dimension就动态的刷新了，这时取到的ChildCount就是实际的正确数量值了。
通过跟踪Adomd.net(8.0)的Member类的ChildCount属性，我们可以清楚地看到，这个1000其实就是一个在系统未取到真实的ChildCount时的一个默认数值：
// return ( long) ( Convert. ToInt32( AdomdUtils. GetProperty( row2, "DisplayInfo"), CultureInfo. InvariantCulture) & 0xffff);
虽然有这么一个不准确的ChildCount，但是只要该含有Rolap类型Dimension的Cube一旦被访问过，即下次查询是"热查询"，这个ChildCount就会是正确的。不过微软建议Rolap类型Dimension一般用于超大量(10M个以上)Member的Dimension，所以我们应该不会太多的用到Rolap类型Dimension，所以Adomd.net默认返回1000似乎也算是可以接受的。
本文转自博客园鸟食轩的博客，原文链接：http://www.cnblogs.com/birdshome/，如需转载请自行联系原博主。
