1. Ошибка Initialization of the data source failed при коннекте с Analysis Services по HTTP из Excel 2007 и ранее.
Предполагается, что мы дошли до рис.20 в предыдущем посте и сказали Next. Появляется вот такой экранчик с просьбой обозвать более по-человечески созданное соединение и дать ему описание.
рис.1
Жмем Finish, Excel спрашивает, в каких ячейках расположить сводную таблицу (график), в которые он прочитает данные из кубика:
рис.2
Жмем ОК и получаем ошибку:
рис.3
Может быть более многословный текст:
Initialization of the data source failed.
Check the database server or contact your database administrator. Make sure the external database is available, and then try the operation again. If you see this message again, create a new data source to connect to the database.
Errors in the OLE DB provider. An error occurred while loading the connection dialog box component for prompting.
рис.4
Короче, жалуется на какие-то траблы с соединением несмотря на то, что только что (на рис.20) все кубы прекрасно виделись.
Обычное соединение по TCP/IP (имя сервера без всякого http) и интегрированной аутентификации непосредственно в домене, где расположен сервер Analysis Services, из того же экселя происходит нормально.
Причина состоит в том, что Excel не держит постоянно открытое соединение с Analysis Services. Он может его закрывать и открывать по мере необходимости. В то же время введенный при организации соединения пароль (рис.19) он нигде внутри себя закэшировать не сподобился, и при повторном открытии соединения он его попросту забыл.. Мне известны два способа вылечить эту ситуацию. Оба никуда не годятся.
Способ первый. Разрешить анонимный доступ к виртуальной директории msolap. Делается в том же месте, где включалась базовая аутентификация на рис.15 в предыдущем посте. В качестве анонимного пользователя выбрать товарища с правами на Analysis Services:
рис.5
Возвращаемся в Excel, жмем на рис.2 ОК и успешно коннектимся к кубу. Справа в списке сводных полей видим знакомую структуру AdventureWorks.
рис.6
Ровно так же к кубу теперь может законнектиться любой проходимец. Уберите анонимный доступ.
Второй способ, тоже не ах, состоит в том, чтобы сохранить пароль в строке соединения.
В Excelе выведите список существующих соединений Data -> Existing Connections и нажмите внизу диалога кнопку Browse for More.
рис.7
Откроется окно с.odc-файлами, каждый из которых хранит информацию о своем соединении из Excel.
рис.8
Удалите файл с только что созданным соединением.
Закройте диалог и создайте соединение заново, начиная с рис.18 предыдущего поста. На последнем шаге (см.рис.1 этого поста) отметьте галку Save password in file. Будет выдано предупреждение
рис.9
Нажмите Yes. Соединение установится нормально и, вместо ошибки рис.3 появится заготовка сводной таблицы со структурой куба рис.6. Однако пароль действительно хранится в .odc-файле соединения (рис.8) в открытом виде, и каждый, кто в состоянии открыть его Notepad'ом, сможет свободно его прочитать:
рис.10
Как кто-то заметил в форуме, security not perfect but a lot better than Anonymous logon.
Также обратите внимание на последний пост в переписке:
Another way not to save the password in the file is:
In Control Panel -> User Acounts -> Manage Passwords (password saved were, where the admin could protect it)
Add the server with the information of the user (basic authentication)
In Excel use normal [windows authentication] and point the server to HTTPS msmdpump.dll
This should works. But I've a problem with a proxy server in the middle.
2. Совершенно аналогично экселю делается строка соединения изнутри приложения. Следует заметить, что при ошибочных credentials выдается совершенно мутное сообщение, могущее сбить с толку. Я наткнулся на эту ситуацию случайно, когда опечатался в пассворде. Вместо того, чтобы со всей партийной прямотой заявить, что такого не значится, AS говорит: "The connection either timed out or was lost". Видимо, чтобы враг не догадался. Или это аяец воду мутит, не знаю. Стоит иметь в виду, чтобы не бросаться копать в неправильном направлении.
рис.11
В Интернете народ по поводу этой ошибки советует всякую чушь из серии протереть фары и попинать колеса. Из дельного есть замечательная статья "Resolving Common Connectivity Issues in SQL Server 2005 Analysis Services Connectivity Scenarios" из серии "SQL Server Best Practices". Первым пунктом в ней дается сермяжный, но действенный совет проверить, is there a typographical or other error in the connection string, что доказывает, что автор тоже наступал на эти грабли, следовательно, излагал материал из действительно практического опыта, а не переписывал Books On-Line, за что заслуживает респект. К сожалению, я эту статью еще не читал, а потому просто нажал на View Detail... в окне ошибки.
рис.12
где и прочитал в InnerException истинную причину ошибки. Все сразу понятно. Почему бы не выдавать ее дальше наружу - вопрос философский.