tSQLt and the INSERT EXEC Problem

A proposed solution to the INSERT EXEC problem in tSQLt

Exploration of SQL Server 2016 Always Encrypted – Part 3

In this third article of the exploring SQL Server 2016 Always Encrypted series, Greg Larsen looks at the differences between an Always Encrypted column that uses an encryption type of Deterministic and those that use encryption type of Randomized.

Centrally collect replication conflicts and send an alert

Automatically capture replication conflicts and generate an automated email notification.

Who's Got a Preteen SQL Server?

This week Steve Jones wonders about the age of your instances and whether you are planning on upgrades or aware of how many out of support instances you might have.

How to read data from multiple Excel worksheets with SQL Server Integration Services

Read this tip to learn how to import data from multiple Excel worksheets into SQL Server using SSIS.

SQL Azure Performance Benchmarking

An evaluation of the SQL Azure Database Performance Levels recommended by the DTU Calculator service, and a comparison with on premise SQL Server performance.

The New Operating System

We have an operating system for how our organizations are run. Steve Jones talks about a new one that might be important for the world rules by software.

Monitoring In-Memory OLTP: What's Important?

In-Memory OLTP has evolved to be a great solution. However, a production system that uses it needs careful monitoring to avoid stress conditions becoming problems. As with many new features of SQL Server, it pays to plan a monitoring strategy to ensure that you are alerted as soon as possible when things go awry.

Queues in Databases

The idea of using a queue in a database is one that some people try to avoid, preferring to use a messaging service. However, Steve Jones notes that this isn't always necessary.

Stairway to Database Source Control Level 4: Getting a Database into Source Control (Distributed Repository)

Now that we have our database under source control, we will want to share our work with other developers. If we are in a centralized source control system, our changes may be committed straight into the central repository.

When we are working in a distributed system, it means pulling down any changes from other developers, addressing any areas of conflict, and pushing our changes up to allow others to benefit from our work. This allows our changes to be synchronized with the changes other developers have made.

This level is principally about setting up a distributed source control system, namely Git, and how to commit database development changes to a local repository, before pushing them into a remote 'central' repository for sharing with other developers.

The next level will delve a little deeper into Git's versioning mechanisms, and show some examples of how to share database changes during development, and how to deal with conflicting changes.