摘要:上个MDX项目移交一个多月之后，有同事跑过来和俺切磋关于MDX的问题。听完同事的介绍后，俺当时产生了两个感想。一个是感慨自己居然能以这么快的速度将上个项目积累的关于MDX的知识忘的一干二净；二个是当时做MDX解析的工作时抱怨说其语法过于烦琐，现在面对实际项目中客户的种种奇怪需求，真恨不得MDX的语法再复杂个十倍。 言归正传。考虑这样一个场景，有一个大Cube存储着网站的访问历史数据，其中有一个维就是网站中各个网页的URL。用户这个貌似很合理的要求是这样地。用户指定一个URL，将这个URL做为Slicer进行切片，然后察看和该网页相关的多维数据。反映到MDX语句中呢，就是在MDX屁股后面再添上一个”Where ([URL].[User Defined URL])”，其中” User Defined URL”是用户要输入的页面地址。Ok，需求很明确，也很合理，指定页面察看嘛，用个Where就打发了。别高兴太早，问题在后面。用户输入正确的网页地址，ok，运转正常；用户输入一个错误网页地址，一个异常从UI上跳出来，说找不到这个Member。输入错误了当然找不到，问题是在ASP系统中俺们使用OWC来和后台service交互， 这错误没法捕获。换句话说，要么您就保证提交给server的MDX语句完全正确，要么就给用户蹦出一个谁也不明白的异常。如果您有把握说服用户喜欢上这个异常，您就不必往下看这篇文章，否则俺们就一起来看看如何避免不存在的Slicer提交给server。 首先要作的工作是判断用户输入的这个Slicer（也可以理解为member，因为目前用户只是要求基于单个维度来切片，不保证用户看了我这篇文章后胃口大开要求同时输入多维进行切片）是否是一个存在的Member。Filter函数配合InStr函数可以搞定这个。 Filter( [Time].Members,InStr([URL].currentmember.name, "ProductView.asp")) 上面这段MDX干的活就是，遍历URL维中的所有member，如果这个member的名字包含“ProductView.asp”（这个就是用户输入的页面地址），ok，扔到一个新set里，最后把这个set做为输出。如果用户输入的页面地址不存在，也就是没有任何member的名字能够和这个页面地址匹配，这个新set就为空。俺们要做的事情，就是避免这个set为空。 那么怎么避免Filter函数得到的set为空呢？耍点小花招。看看下面的代码： TopCount( Union(Filter( [URL].Members,InStr([URL].currentmember.name, " ProductView.asp ")), {[URL].DefaultMember}), 1) 必须承认这是一个讨巧的招，不过好使就行，是不是名门正派的套路，就管不了这么多了。首先让Filter函数得到的set与{[URL].DefaultMember}做一个Union操作，这样如果Filter函数的结果set为空，则会返回set会至少包含一个{[URL].DefaultMember}，保证了返回set肯定不为空。然后再在外面套一个TopCount函数，将排列在第一个member提取出来，这样，如果Filter函数不为空，整个结果就是Filter函数的输出，如果Filter结果为空集，则返回的是一个包含 [URL].DefaultMember的集合。需要说明的是DefaultMember是事先预定义的一个计算成员，其各个measure的值永远都是-1。至于为啥要定-1，think。 Ok，到这，俺们已经得到了一个包含且仅包含一个（真绕口，Rap？）Member的set，这个Member就是用来做 Slicer的原料。但是Slicer只可以是Tuple，不可以是Set，还得费点事将Set转换为Tuple。查遍MDX函数，找不到SetToTuple或者TupleToSet。看来只又再出偏招了。注意到Set的字符串形式是什么？”{[ ProductView.asp]}”，Tuple的字符串形式是”([ProductView.asp])”，，，，get it。 将Set转换为字符串，然后脱去前后两个大括号，再添上两个圆括号，ok，这不就是Tuple了吗 J 说的轻飘，写起来苦： Where (StrToMember( mid(SetToStr(TopCount( Union(Filter( [URL].Members, InStr([URL].currentmember.name, "ProductView.asp]")), {[URL].DefaultMember}), 1)),2, Len(SetToStr(TopCount( Union(Filter( [URL].Members,InStr([URL].currentmember.name, " ProductView.asp]")), {[ URL].DefaultMember}), 1)))))) 这就是最后这个Slicer的模样，是不是看上去有些臃肿状。没办法，在向大家介绍MDX的时候，为了安抚人心，俺常说MDX语法虽然复杂，但是编写的时候往往比SQL来的简洁。但是，在实际应用中，正因为MDX太强大，为了迎合客户的种种BT要求，写出的MDX语句往往也很BT。这正应验了Leader的名言：客户有多BT，程序就有多BT。...[阅读全文]

摘要:和摩尔定律一样，软件行业也有一个流行的定律，1.0版本永远是不好用的。即使是MS也不例外。Information Bridge Framework（IBF）就是一个典型案例。   先解释一下IBF是个啥玩意。MS推出IBF，针对的应用群体称为Information Worker，这个词官方翻译为信息工作者，其实白话就是信息工人。每天需要对着计算机，写文档报告方案的同志，就可以被称为信息工作者，项目经理，人事经理，销售经理，那都可以广义的包括在内。拿销售经理来说，用Word写份年度总结报告，总免不了要填若干或真实或虚假的数字。哪里能够找到这些数字呢？他得从word切换到公司内部的MIS系统，找到这些数字，然后copy到这个word文档上来，如果只是数字也就罢了，现在为了这个报告PP一点，老板更好理解一点，销售经理还想搞个曲线图出来。这难为了他，打字都跟啄米似的，更别提捣鼓什么曲线图了。要是在Word上有这么个按钮，一按，曲线图就贴到了word上，这就美滋滋了。咱们先别管这位销售经理的工作态度问题，从技术的角度出发，他还是很有创意的。归纳起来，再提高一点，他要的就是这么一个工具，能根据目前在文档中所操纵的信息和状态，自动从后端支撑系统（公司内网的MIS，ERP，CRM，或外网）提取需要的数据、信息，融合到文档中来。IBF就是这样的一个工具或称架构。   看上去挺美的，交给俺们这些IT工作者来实施，就头大。光一个简单的demo，构建指南就有64页，俺拿出学习三块手表的精神和态度，认认真真从头到尾地琢磨了好几遍，也愣没在俺这笔记本上给整出来，实在无法，格了俺PC机的命，操作系统office什么的全换新的，该打的补丁一个不拉，总算是在单机上看到了IBF的尊容。   　     想各位也没有兴趣和时间来听IBF的技术细节，简单概括起来，IBF分为服务器和客户两端，服务器端存放各种MetaData，数据打哪来，到哪去，中间要经过哪些转换步骤，这都在服务器端存着，客户端有这么一个任务栏，当您在office程序中输入特定字符串时，客户端可以感知到，并在任务栏上显示出和这个特定字符串相关的数据，信息和操作。   俺现在使的是IBF1.0，其他安装配置的苦水暂且按下不表，单是这个MetaData，俺真想说俩句，这个MetaData的架构，设计的是精巧有余，大气不足。概念的层级太深，在Demo中，有Item居然达到了8级别。一本构建指南读下来，云里雾里，一会东西，一会南北，demo是做好了，可怎么做好的，整体上是个嘛结构，完全没有概念。另一头是这个metadata设计器，写这个metadata设计器的同志是个高手，就是太高手，他用的顺手，俺就用的不顺手了。俺的显示器上大概和这位高手的不太一样，设计器form右边短了50像素，若干按钮显示不出来，俺只能根据指南上的图片，用tab键来尝试。单是完成最简单的功能－根据word文档中的人名，在任务栏上say个hello，俺统计了一下，用这个设计器大概需要弹出40个以上的输入信息界面。所以没有耐心的同志最好不要玩IBF。   俺知道有些同志喜欢挑战自我，被俺这么一说，还非要装一个玩玩不可。Ok，提供些tips。   １：最好不要在同时安装vs.net 2003和vs.net 2005的机器上玩IBF，至少我没有玩出来，后来卸载vs.net 2005和.net framework 2.0之后才ok。Vs.net 2005内建word application支持的类库好像和IBF，VSTO等东东有冲突。 ２：安装客户端的时候，需要输入metadata服务器的地址。这里有个大陷阱，在论坛上还有好多人问起来。这个metadata服务器暴露出一个web service，指南上说填入这个web service的地址就ok，俺就输入一个http://localhost:8081/IBFReadService.asmx。死活都不能通过检测，说服务找不到。问论坛有的说不要用机器名，要用ip，有的说用localhost不用ip，都不灵。整了老多天，最后才发现，填入http://localhost:8081就可以了，后面缺省的不用填，填了就错。真是没办法，这1.0的东西就是容易着他的道。 ３：另一个小心的地方，是安装smart tag。指南上说编译smart tag项目，然后注册，就ok了。其实还需要为这个smart tag配置安全性，具体就是在smarttag目录下执行CaspolAddFullTrust.bat就可以了，还有UIControl部分，也如法炮制一把。其实这高人把bat文件都给写了，就是不在文档里面说明。这不存心让人受累嘛J   Ok，下面是IBF的一些资料连接，供准备挑战自我的同志参考： IBF介绍：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_ibf2003_ta/html/ODC_ibfintro.asp 一个关于IBF比较好的网站：http://www.officezealot.com/ibframework/ IBF的论坛：http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.office.informationbridge&lang=en&cr=US IBF@MSDN：http://msdn.microsoft.com/office/understanding/ibframework/default.aspx    ...[阅读全文]

摘要:第一把在blog里面贴图，结果显示不出来，很是头大。有爱心的同志建议，是中文图片名的问题，换英文图片名就ok了。美滋滋地换个英文名的图片上来，总还是有问题。图片上载无问题，单图片浏览无问题，编辑的时候插入图片也无问题，就是在保存后显示整篇文档，就出问题。中文、英文的名字都试过了，幸亏语言方面俺没有天赋，否则试一晚上把地球上所有语言都轮个遍也试不出来。 想在编辑的时候能够显示图片，那这图片的连接应该是没有问题的。换个外部的图片链进来，ok，也能正确的show。难道是后台替换了图片的连接地址？不会吧，被玩死系列之四这么快就找到素材了。察看显示不出来的图片的地址，是“http://images/blog.joycode.com/grapecity/1016/o_中文亦能显示哦.jpg”注意是双引号里面的部分。 然后在管理模式下察看图片的原图，其地址是：“http://blog.joycode.com//images/blog.joycode.com/grapecity/1016/o_中文亦能显示哦.jpg”。慢着，为什么image前面是两个斜杠？ 去掉双斜杠中的一个，地址变为：“http://blog.joycode.com/images/blog.joycode.com/grapecity/1016/o_中文亦能显示哦.jpg”。图片照样可以显示出来.... 俺从相册中选择这张图片，然后察看其原始图片，然后copy之，转到文档编辑区，贴入图片，ok，图片show出来。注意哦，这时show的图片地址是image前面为双斜杠的地址，但是在实际显示出来的文档中，不知道是服务器解释的问题，还是IE的毛病（俺想问题应该是出在服务器端），将image前面的双斜杠解释成了目录上移操作，ok原始的图片地址：“http://blog.joycode.com//images/blog.joycode.com/grapecity/1016/o_中文亦能显示哦.jpg”经过目录上移后就变成了俺们在最后文档中看到的“http://images/blog.joycode.com/grapecity/1016/o_中文亦能显示哦.jpg”。当然是看不到图片了。 之其所以然后，解决的方法就简单了， copy图的时候，不要从image前面是双斜杠的地址来copy，尽管在ie中这个地址的图片也能show出来，copy image前面只有一个斜杠的地址所对应的图片，然后插到文档中，就ok。 这么小的图片显示问题俺也得耗到半夜才能明白通透，技术这东西，真让人爱恨交加。此刻，俺是恨多过爱，希望明早起来，技术又能恢复迷人的魅力。...[阅读全文]