None of my SSAS projects will deploy & process with the Wizard. They will always deploy & process directly from BI Studio.
As a test, I built a very simple project. Two measures from a fact table, and one very simple dimension, from the same fact table.
The target DB is hosted on a server where I am admin.
When I attempt to deploy with the Deployment Wizard, I do the following:
1. Run the Wizard locally on the target server, under my login (which has admin rights).
2. Select the .asdatabase produced by the 'Build' from BI Studio.
3. Choose the target server and database.
4. Use the default settings for Partion & Role Options (the test DB has no seperate partitions or role definitions)
5. Use the default settings for Configuration Options
6. Choose Full Processing for Processing Options
... then I confirm the deploy...
Then I will always get:
"Errors in the OLAP storage engine. An error occurred while the 'xxxx' attribute of the 'yyyy' dimension from the 'zzzz' database was being processed."
When I do the same for a more complex project, the attribute and dimension that fail are random, changing from one deploy to the next. Unlike processing from BI Studio, no additional detail is given.
As an aside, when I select 'Process in Single Transaction', I get something different:
"The following system error occurred: Logon failure: unknown user name or bad password"
I'm not sure why this happens for that option, but not when it's turned off. I (think) I've tried all the different impersonation methods in the Configurations page, but always get the same result.
Seperately, I have tried instead to process an XMLA file from a SQL job, but get even less information in the errors there.
I've also looked at using ASCMD, but I dead ended there due to it only being availabe as source code (I don't have the full dev environment at present, so I don't think i can compile the project, unless there is some of distributable make utility).
The sound of a deadline whooshing by was about a week ago... any ideas much appreciated.
Your processing errors have nothing to do with the way you send the deploy command or the way you send processing command.
Most likely you got some referential integrity problems in your domain or fact tables. Simple cases where during processing of an attribute Analysis Server cannot find matching keys.
Most simple and brutal way is: tell it to ignore processing errors- you will find such options in the processing dialog.
The "cannot login" errors are pretty straightforward. If you get it during processing, it means Analysis Server cannot access the relational database. That could be due to the security settings of the datasource object. Or due to the Analysis Server's service account not having permissions.
If your XMLA script fails with such error, that could be simply becuase it couldnt access Analysis Server.
One general suggestion is: Try searching this forum, tons of information is avaliable here to you.
HTH
Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Edward,
I don't think it's the design. I've been processing it for weeks now using BI Studio, deploying to the exact same server - no errors, the cube works perfectly. No tricks like ignoring key errors either implemented or required - all the data, for both fact and dimensions, is from a dumb flat table. And, just to prove it to myself, I built the equivelent of a "Hello World"... with one measure, and one single attribute dimension. Totally basic - the dimension is just a text column in the fact table. Again, it always fails to deploy in the wizard. Again, it always deploys ok from BI.
As for the login issue when I select single transaction, I've now realised I can use SQL Profiler to see how far the wizard is getting with regards to RDBMs access - so I'll take a look at that on Monday.
I also think I'll make the test project even dumber on Monday. Just one row of fact data, and two coumns. One column for a measure, with a '1' in it. And one other column for a dimension, with 'Hello' in it. I don't think I can make it dumber than that.
My gut feel is that it's something authentication related but I just can't quite pin it down at the moment.
Regards,
Paul
|||OK I've now solved this - it was authentication related as I'd guessed. I'm not sure I understand authentication & permissions configuration in SSAS, but here's what I did:
In properties for the solution:
Configuration Properties: Deployment: Build - set Remove Passwords to False
In Data Source designer for the data source:
Impersonation Information: Selected 'Use a specific user name and password' - entered credentials for a user account. (The account has admin permissions on the box. I don't know if that's significant.)
No comments:
Post a Comment