昨天被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时的一个默认数值:
![ChildCount1000.gif](https://images.cnblogs.com/cnblogs_com/birdshome/NormalArticle/2006/ChildCount1000.gif?x-oss-process=image/resize,w_1400/format,webp)
// 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/,如需转载请自行联系原博主。