Странно, но иногда на семинарах обнаруживается, что народ искренне полагает, будто в MDX-запрос в отличие от SQL нельзя передать параметры. Я думаю, это заблуждение происходит скорее всего оттого, что в SQL Server Management Studio в редакторе Analysis Services MDX Query нет возможности задать параметризованный запрос. Синтаксис MDX поддерживает параметры в запросе, а почему их не удосужились приспособить в SSMS - вопрос к тем, кто ее писал. Параметры можно передать, написав классический XMLA. Если вместо Analysis Services MDX Query открыть в SSMS Analysis Services XMLA Query и изобразить что-нибудь навроде
<Execute xmlns="urn:schemas-microsoft-com:xml-analysis">
<Command>
<Statement>
select [Measures].members on 0,
Filter(Customer.[Customer Geography].Country.members,
Customer.[Customer Geography].CurrentMember.Name = @CountryName) on 1
from [Adventure Works]
</Statement>
</Command>
<Properties>
<PropertyList>
<Catalog>Adventure Works DW 2008R2</Catalog>
</PropertyList>
</Properties>
<Parameters>
<Parameter>
<Name>CountryName</Name>
<Value>'United Kingdom'</Value>
</Parameter>
</Parameters>
</Execute>
Скрипт 1
можно видеть, что параметризованные запросы прекрасно работают (см. Рис.1). Еще возникает недоумение, что бы в синтаксисе XMLA было не сделать однотипными элементы <Properties> и <Parameters>? Например, вместо
<Properties>
<PropertyList>
<Catalog>Adventure Works DW 2008R2</Catalog>
</PropertyList>
</Properties>
сделать, как у параметров:
<Properties>
<Property>
<Name> Catalog</Name>
<Value> Adventure Works DW 2008R2</Value>
</Property>
</Properties>
или наоборот? Не знаю, Моше виднее.
Рис.1
К сожалению, редактор XMLA в SSMS отображает результат запроса в его исконном виде XML и не позволяет его отобразить в виде наглядного набора ячеек, как это умеет делать редактор MDX Query:
Рис.2
Ровно так же параметризованный запрос можно выполнить из приложения. Программно заслать в AS произвольный XMLA-запрос можно, например, средствами SOAP, как рассматривалось в одном из предыдущих постов. В ADOMD.NET, как мы помним, в AdomdCommand можно засунуть только начинку элемента Command. Элементы Properties и Parameters в XMLA-запросе находятся на одном уровне с элементом Command и в его InnerXml не попадают. Для их передачи используются коллекции Properties и Parameters класса AdomdCommand:
using System.Data;
using System.IO;
using System.Xml;
using System.Diagnostics;
using Microsoft.AnalysisServices.AdomdClient;
class Program
{
static void Main(string[] args)
{
AdomdConnection cnn = new AdomdConnection(@"Data Source=http://192.168.0.29/msolap/msmdpump.dll; User ID=192.168.0.29\\Administrator;Password=cth%tyflf");
cnn.Open();
AdomdCommand cmd = new AdomdCommand(
@"select [Measures].members on 0,
Filter(Customer.[Customer Geography].Country.members,
Customer.[Customer Geography].CurrentMember.Name = @CountryName) on 1
from [Adventure Works]", cnn);
cmd.Properties.Add("Catalog", "Adventure Works DW 2008R2");
cmd.Parameters.Add(new AdomdParameter("CountryName", "United Kingdom"));
CellSet res = cmd.ExecuteCellSet();
for (int i = 0; i < res.Axes[0].Positions.Count; i++)
{
Debug.WriteLine("");
for (int j = 0; j < res.Axes[1].Positions.Count; j++)
Debug.Write(res.Cells[i, j].FormattedValue);
}
cnn.Close();
}
}
Скрипт 2
В данном случае название базы перешло из элемента Catalog родительского элемента PropertyList родительского элемента Properties
<Properties>
<PropertyList>
<Catalog>Adventure Works DW 2008R2</Catalog>
</PropertyList>
</Properties>
(Скрипт 1) в член коллекции cmd.Properties["Catalog"] - см.Скрипт 2, а параметр запроса - из элемента
<Parameters>
<Parameter>
<Name>CountryName</Name>
<Value>'United Kingdom'</Value>
</Parameter>
</Parameters>
(Скрипт 1) в член коллекции cmd.Parameters["CountryName"]. Можно посмотреть на результат и убедиться, что он совпадает с рис.2 с точностью до форматирования.
Рис.3
В данном примере по-прежнему используется доступ к Analysis Services по HTTP. Если дело происходит в пределах одного домена, то, как отмечалось в одном из предыдущих постов, можно заменить строку соединения на "Data Source= 192.168.0.29". Тогда бы SOAP шел непосредственно по ТСР.
Возникает вопрос, неужели верхнеуровневость ADOMD.NET по сравнению с SOAP не позволит выполнить из нее полноценный XMLA просто как он есть? Без того, чтобы предварительно сепарировать его на команду, свойства, параметры и т.д. и рассовывать это хозяйство по разным объектам ADOMD.NET. Смотрите следующую серию.