As they say, One man’s fish is another man’s poisson, so my oddity might be your delight, but here are a few things about the SQL Management Studio (SMS) and BI Development Studio (BIDS) environment separation that seem a bit odd to me.
Analysis Services. SMS prevents you from changing the design of a live Analysis Services database. (You could it Beta 1, but now SMS is a “management” environment.) But you can still make changes to a live database, you just have to connect to it through BIDS. So BIDS now has three ways to open an existing project: 1) open the project files (a true development environment), 2) import to a project from a deployed database (useful if you haven’t been using source control and screw up your working copy), or 3) attach to a live database (defeating the separation of production and development).
Reporting Services. Maybe I just haven’t yet discovered how to do it, but I can’t find a way in SMS to move a report to a new folder or to export a report to RDL. Also, even though Reporting Services tries to let you script actions, sometimes the script ends up empty, and sometimes it’s unusable—for example the script of a report upload includes a byte array of the report, rather than the file location.
DTS Server. In order to register the DTS Server, you must first start the DTS Service which, by default, is disabled. The philosophy is that potentially optional services should only be activated by people who can use them. By that logic why not disable the Analysis Service, or even the SQL services. Also, you can’t execute a package from SMS (although you can from BIDS); to execute a package, you have to run a separate utility, and DTS doesn’t even try to let you script actions from SMS.
General. And, of course, there’s the issue of having BIDS as a separate environment from Visual Studio—if you’ve got a development solution, why shouldn’t it include the .Net assemblies as well.
It will be interesting to watch the environments continue to evolve as we move toward product release.
- Reed