I'm implementing a tabular database in SQL Server Analysis Services using compatibility mode 1400. I started the development using integrated workspace, later, due to business demands, I had to switch to an external workspace database. I've had no problem in the process, and I could continue developments with almost no hassle.
Today, unfortunaley, when I try to process the workspace database from SSDT, the process starts, but it gets stuck on "operation in progress, validating credentials".
Have anyone experienced this? Can anyone point me in the right direction to investigate this problem?
I'm using version 2.5 of Analysis Services Project.
I just found out that the 2.5 version of Analysis Services Project suffers for this problem. A simple update should fix the problem.
Related
I would like to know the steps involved in migrating the Oracle Iplanet webserver(v6) to WAS Liberty profile. Also please let me know the feasibility and the challenges involved.
The changes needed will depend on the application being migrated. You can use the binary scanner tool to scan your application for changes needed to migrate to liberty. Run the tool against your war/ear/jar file(s) with the --sourceAppServer=other --targetAppServer=liberty options.
I have a job set up to Incrementally sync my analysis database in TFS 2015. This has been working without issue, up until recently where it now just runs and runs without completing.
The job never completes so there is no error message, but I am concerned that it will start to impact the operation of the system.
Can someone let me know;
Can I safely "kill" the job (What's the best way to do this?)
What I can do to stop this from happening repeatedly
If you are talking about Analysis Services Sync job. You can try to follow the article below to manually process data warehouse and analysis services cube for Team Foundation Server.
http://msdn.microsoft.com/en-us/library/ff400237.aspx
If manually processing still received the same issue, you can try to delete the Tfs_Analysis database and recreate it using TFS Admin Console. To delete the Tfs_Analysis database, you can connect to Analysis Service using Microsoft SQL Server Management Studio, expand the Databases node, and delete the Tfs_Analysis database.
To recreate the Tfs_Analysis database, please refer to the following
steps:
Launch TFS Admin Console>>Application Tier>>Reporting, in the right panel, click Edit to open the Reporting windows.
Under the Analysis Services tab, input the Tfs_Analysis under Database textbox, and re-provide the required account under Account for accessing data source.
Click Ok to generate the Tfs_Analysis database in Analysis Services.
Click Start Jobs and Start Rebuild to rebuild warehouse and the Analysis Services database.
The "SQL Server Database Migration Wizard" aka SQL Azure Migration Wizard previously located at http://sqlazuremw.codeplex.com/, but it is gone.
I attempted to search via Google for its new home, but I cannot find it.
Does anyone know where this tool has gone?
It is replaced with Data Migration assistant..
Data Migration Assistant (DMA) enables you to upgrade to a modern data platform by detecting compatibility issues that can impact database functionality on your new version of SQL Server and Azure SQL Database. It recommends performance and reliability improvements for your target environment. It allows you to not only move your schema and data, but also uncontained objects from your source server to your target server
DMA replaces all previous versions of SQL Server Upgrade Advisor and should be used for upgrades for most SQL Server versions (see below for supported versions).
References:
https://blogs.msdn.microsoft.com/datamigration/dma/
You can now find it here: https://github.com/adragoset/SQLAzureMigration
(I searched for a long time too before I found it.)
That code did not work out of the box for me. Took me about 30-40 minutes to get it to build. But seems to work fine once I got it to build and run.
I am initiating a huge team to use SSRS for their reporting purposes. Previously I used to develop the reports and send it across to the DBA to implement it, but my recent posting is into a company where they Build once and deploy many process.
I would like to know how reports I developed on DEV environment be pushed into the upper environments with an automated build process.
Thanks
If we have 3 developers working on the same Biztalk project what is the best way to set up our development environment?
We are using TFS to store the Biztalk project.
Should we use 1 sql server and 1 Biztalk server and then have 1 or more developer machines that access the sql and biztalk servers? The issue we get with this is when 1 developer compiles and deploys their changes it can effect other developers if they are also trying to compile and deploy their work.
Should we have each developer host their own complete sql and biztalk server for local development either on their machine or within their own virtual machine? The problem we find with this is that each developer could modify their server settings and those settings are not stored in source control. This can cause confusion when changes are deployed to a testing server. Another smaller issue is that each developer would need to have sql server, biztalk server and windows server installed.
Is there another way to set up a multiple developer biztalk development environment?
You will always want to have each developer have a complete BizTalk installation on their own machines. Believe me, it doesn't work otherwise, as you'll just keep getting on each other while trying to deploy/test/debug changes.
That said, you will also want a centralized dev/test environment where you deploy your code for more complete integrated testing and making sure all the changes from everyone are seen together.
Your point about configuration is true, but only up to a point. This is because you should make your solution configuration part of your source code and keep it in source control as well. This is particularly important once you're a bit ahead in your development as you'll need to start maintaining multiple versions of your binding files for each environment (dev, test, production and so on).
tomasr is right. Also, if you have decent hardware and lots of RAM, you may want to setup a VM image of your full developer environment, then share this will all your team. Not as fast as native hardware, but does allow you to roll back changes, replace your VM if you really mess up and everyone then has the same environment – ideally close to the target one.
Setting up a continuous build server is also a most, if your projects are small, you can get each checkin to cause a full build, BizTalk deploy, export of MSI and then run tests. Later as your solutions get more numerous you might have to move to a continuous build of C# changes only, then say nightly or several times a day, you do a full. We have done this with CruiseControl.net, Nant, nunit and various power shell scripts, it was pretty time consuming, but each morning we come to work to find a fully compiled, deployed, exported and tested set of BizTalk solutions ready for the test team.