The other day I needed to install SQL Server 2008 R2 SP1 on a machine. Because I was installing it on a Windows Server 2003, I couldn’t simply install SQL 2008, I needed to install R2 SP1 because SQL Server 2008 doesn’t like being installed on Windows Server 2003. Unfortunately, SQL Server 2008 R2 SP1 doesn’t have a base installer – there’s only an upgrade installer. So, I was required to perform a procedure call “slipstreaming”. A slipstream installation is one in which the upgrade pack is added to the base installer and installed initially instead of installing the base and upgrading. In this way, SQL Server 2008 R2 SP1, because it’s compatible with Windows Server 2003, would not complain at install time.
This week, while moving a client’s VM to Windows Azure, I was also required to upgrade their database from SQL 2005 to SQL Azure. While not extremely difficult, there were a few gotcha’s along the way. These “gotacha’s” were primarily features that had been deprecated. Those deprecated features aren’t the purpose of blog post, however. This post is addressing a connection string issue.
On one of my SharePoint installations, I was having a ton of issues with SharePoint Search. I had created a SharePoint Search Application post-install with a different service account. The search application starting adding an additional 10 MB to the individual log files. I would reset the IIS application pool, but would see the search application continuing to run.
There’s a lot of times when people need to restore databases from a network (UNC) path. There are two ways of doing this:
The other day I was needing a way to test some LINQ statements from an application which rebuilds a database while performing some calculations. The rebuilding process is just shy of 24 hours.
Besides, there have been numerous other times in which I needed to test LINQ statements.
Troubleshooting LINQ can be difficult at times due to it deferred execution – the statement is executed as the last possible moment. I wanted a tool similar to SQL Management Studio in which I could run LINQ queries against a database. Thus, I stumbled upon (actually, it wasn’t very hard to find) LINQPad.
Since, finding it, LINQPad has allowed me to test my queries prior to implementation in the application. Therefore, I can better predict the result instead of waiting through a long process and/or waiting for QA to troubleshoot.
LINQPad allows the user to run C#, VB.NET, F# and SQL statements/expressions against the database – very flexible and extremely helpful. LINQPad’s flexibility allows the connection’s data context to be LINQ to SQL, Entity Framework and WCF (OData).
Take a look at LINQPad at www.linqpad.net.
I was asked to take over a TFS installation. Apparently, there was no one, previously, knowledgeable in administering Team Foundation Server because there were many installation and configuration issues – it was a mess.
One such issue was misassignment of user permissions. For instance, the business needed multiple users to have access to the TFS analysis cube in order to generate reports and pivot tables in Excel. The business’s solution to granting users “read” access to the cube was to grant them TFS Administrator privileges. In fact, there were over 20 users who were authorized as Team Foundation Administration Console Users.
By doing this, not only does the user have incredibly insane permissions around TFS, but they have administrative privileges (Read/Write) to the analysis cube – they would be added as a member of theTfsWarehouseAdministrator role group on the analysis server.