Recently, during a pre-conference seminar that I presented, the group and I had a long discussion about why there would be a need to add a nonclustered index that consisted of the primary key as the key column. This topic also came up in a client training session I presented and in passing with a few peers. Given the topic and the overall consensus that this was a bad practice, I wanted to discuss it in a post and show a reason why creating a nonclustered index with a key column only being the primary key is actually a great optimization for some plans.
This is an archive of the posts published to LessThanDot from 2008 to 2018, over a decade of useful content. While we're no longer adding new content, we still receive a lot of visitors and wanted to make sure the content didn't disappear forever.
Every DBA managing multiple SQL Servers with multiple instances will know the issues with developers, project managers and others that don’t know the importance of the instance name when they request you to take some action. So you can start some e-mail ping pong to get the instance name, open the server documentation or RDP to the server to find the installed instances. But in the time you would need to do this you can write yourself a PowerShell script to get the remote service information.
I don’t need Full outer joins all that often. So when I do I have to think on what it will return me. You can go to wikipedia to find the full explanation on full outer joins if you want to. But in short it is this. Conceptually, a full outer join combines the effect of applying both left and right outer joins. Where records in the FULL OUTER JOINed tables do not match, the result set will have NULL values for every column of the table that lacks a matching row.
It’s October. That means fall, colorful leaves on the trees, soups simmering on the stove, and…horror movies. I love a good horror flick. http://www.flickr.com/photos/kaptainkobold/257491210/lightbox/ It’s also another month of T-SQL Tuesday, edition #35. Our host, Nick Haslam, asks, “What is your most horrifying discovery from your work with SQL Server?” Once Upon a Time Long, long ago, in a land far, far away, I was the very junior DBA at a small company.
On 19 and 20 November, the annual SQL Server Days will take place again. This 2 day event organized by the Belgian SQL Server User Group is the event for all people working with MS SQL Server in Belgium (others are welcome too). From beginner to expert, from developer to DBA, from Excel specialist to BI designer. Why? Because they provide a different track for all the profiles even for the Oracle DBA’s.
This month’s T-SQL Tuesday (#TSql2sday) is being hosted by Nick Haslam (B | T). Nick has a great topic this month. “What is your most horrifying discovery from your work with SQL Server?” I thought about this for a while and even considered bugs that were found in SQL Server itself as the horrifying topic. Given the fact that even horrifying situations and setups come into play, I thought I’d throw out a story from some consulting I’ve done in the past.
One of the people on my team wants to have the ability to truncate tables on the staging database while this person is testing. Here is what Books On Line has about permissions for the TRUNCATED statement The minimum permission required is ALTER on table_name. TRUNCATE TABLE permissions default to the table owner, members of the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and are not transferable.
In my previous post I showed you how I used ServiceStack to do the integration tests with Easyhttp. I also used a different port for each test and thus a different instance of ServiceStack for each of these tests. Of course The Boss was not happy with this. So I went for a look on how to do this the better way. And I found this on Stackoverflow. So thanks to Jason Watts for helping me along.
Introduction Easyhttp uses couchdb for it’s integration tests and this is annoying. You have to install couchdb on your machine and you have to have it running whenever you want to run the tests. It would be so much better if you could just fork Easyhttp and just run the tests without having to do anything special. And there comes ServiceStack to the rescue. ServiceStack can run standalone in a Console app or even in a service.
For the past couple years, .net developers have been embracing various content preprocessors as they become more accessible. For the same couple of years, we’ve been trying to keep up. The dotLess port of the popular .less CSS extension has been getting better by leaps and bounds. It has become almost trivial to embed a javascript compiler in .net these days (thanks to projects like Jurassic), enabling us to support things like coffeescript.