![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Hi Everyone, I am looking for a commercial tool to consume XML/A OLAP data sources. This tool needs to be a proper work tool for analytical data play and reporting. Web based tools are no good to me at this time due to the nature of the network environment. If anyone knows of a tool, something similar perhaps to Proclarity perhaps, that can use an XMLA source as its data provider I would love to know about it. |
#3
| |||
| |||
|
#4
| |||
| |||
|
|
Hi Nigel, I am not sure if they can or cannot. Most of the ones that I have seen want to connect to Analysis Services on SQL Server (directly). I need to avoid this and effectively make the tool independant of the source. Where I work we have a number of different OLAP sources, all needing specialised tools to work with them. They can output XML/A and so I was hoping to be able to simply the user environment by using just one tool for all the different sources of data. I am not sure if this can be achieved, but it would be a real boon for us if it could. Do you know of any tools that might meet this requirement. I have seen some web based ones, but we really would prefer a client rather than a web client. |
#5
| |||
| |||
|
|
Mr.Frog.to.you (AT) googlemail (DOT) com> wrote in message news:1181301697.157450.37990 (AT) q69g2000hsb (DOT) googlegroups.com Hi Nigel, I am not sure if they can or cannot. Most of the ones that I have seen want to connect to Analysis Services on SQL Server (directly). I need to avoid this and effectively make the tool independant of the source. Where I work we have a number of different OLAP sources, all needing specialised tools to work with them. They can output XML/A and so I was hoping to be able to simply the user environment by using just one tool for all the different sources of data. I am not sure if this can be achieved, but it would be a real boon for us if it could. Do you know of any tools that might meet this requirement. I have seen some web based ones, but we really would prefer a client rather than a web client. OK, I see what you mean. I think the issue is that different OLAP servers all have subtly different interpretations of MDX, so client tool makers try and customise the queries they generate or want to know how to interpret the results. That's why they want to connect to named XML/A providers, so they 'know' how to behave, rather than just generically. This blog from Panorama illustrates the problem: www.panorama.com/blog/?p=44 |
#6
| |||
| |||
|
![]() |
| Thread Tools | |
| Display Modes | |
| |