Someone asked about this error this morning and I decided to turn it into a blog post. Basically the person was using the designer/editor in SSMS to delete a row, the table didn’t have a key and the rows were not unique, he got the following error: The row value(s) updated or deleted either do not make the row unique or they alter multiple rows. Let’s see this in action and also take a look at how we can get around this.

I sat down to write a post on testing the core interfaces in the reactive library, and found myself going off onto a bit of a tangent. I made a big enough change to the way everything was set up that I didn’t really feel comfortable including it in the post on testing, but it seemed worth mentioning. So this post was born. I started thinking about an object responsible for managing the subscription, which can be returned as the IDisposable from the observable’s Subscribe method.

Since mirroring has come to the SQL Server feature set, High Availability (HA) has become a much easier, inexpensive and available option. Prior to mirroring, third party software and hardware were the main options to achieve HA. This was due to replication never being accepted as a high availability option. With any solution like SQL Server, growth over time builds a better and more stable solution. This has been the fact with many features of SQL Server, including replication.

I think the reactive extensions library starts to look even better when you start taking into consideration all the cool linq stuff it lets you do with sequences of events. In order to use this we need to add another reference, this time to System.Reactive. It’s interesting that the stuff we are importing with these references becomes available anyplace the System namespace is available – there’s no need to add using directives to our code files.

There are a few methods to execute a SQL Server Integration Services (SSIS) package from T-SQL. Very often the use of xp_cmdshell is the first choice to accomplish this task. Xp_cmdshell has primarily been a system administration extended stored procedure. Many types of extended stored procedures such as this one are meant for tasks that are either manual or very refined and controlled tasks. This is all due to the requirements of the levels of sysadmin roles – or CONTROL SERVER to be exact.

This will be a short post but nonetheless a very important one to me. A good friend of mine, Jason Strate (Blog | Twitter), posted a blog, “What are you thankful for?” In this post he asked all of his readers to also take a few moments and blog about the same. So here we go… Most know that I recently changed jobs. This change was pretty big for me.

SQL Server provides database professionals with several paths in order to import and export data in and out of many data sources and file services. One main task, the Foreach Loop Container, allows for processing large (or small) groups of files with one contained and manageable process. Tasks that once were difficult and required larger scale development efforts have now moved into the realm of the rapid development methodology. Rapid Development is defined as requiring a much lower amount of resources in order to push a process into a production environment.

How many times have you started at a new company or been given a new database that you have to code for and you have no clue how the schema relates? How much time is wasted trying to figure out that schema? If you’re lucky you will be given a database that has at least been developed correctly with foreign keys and a document to accompany it. If you’re not lucky, you’ve just been handed a database with 50,000 objects that you need to document.

Over the past 12 years I’ve received a lot of great suggestions from some very good DBAs on how to best be productive and organized. One of the best pieces of advice I ever read was out of SQL Server magazine a few years back on how to be organized. That advice was to create yourself a DBA repository! What is a DBA repository you ask… Well it’s simple, it’s the one single place where you keep ALL of the things you need to do your job, scripts, logs, executables, trace files, reports.

For someone that is just interested in trying out Unit Testing the number of topics out there can seem overwhelming. From passionate articles about using TDD, to deeply technical articles around the differences in mocking frameworks, to complete sidetracks into architecture theory and how to make code more testable…just learning enough to get started and try out Unit Testing can seem like you need weeks of classes. If you’re just catching up, I’ve been sharing commentary on the costs (and value) of Unit Testing, starting with a brief (intended to be humorous) post, a presentation at the Raleigh CodeCamp, and last weeks discussion of the “Twice as Much Code” issue.